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EXECUTIVE  SUMMARY 


INTRODUCTION 

Control  Data  Corporation  was  selected  to  provide  research 
and  development  effort  for  design  and  documentation  of  a 
large  scale  software  system  using  the  Ada  programming  lan¬ 
guage.  As  a  result  of  this  effort.  Control  Data  developed 
a  design  methodology,  and  validated  the  methodology  by 
the  redesign  and  subsequent  programming  of  selected  functions 
of  the  AN/TSQ-73.  The  design  included  seven  tasks: 

a.  Preparation  of  a  work  plan. 

b.  Project  personnel  training. 

c-  Development  of  a  design  methodology. 

d.  Validation  of  the  design  methodology. 

e.  Redesign  of  the  Missile  Minder  System  and  coding. 

f.  Documentation  of  the  methodology. 

g.  Provision  of  management  reports  on  a  routine  basis. 

The  purpose,  background,  and  scope  of  this  report  are  provided 
in  the  following  subparagraphs. 

PURPOSE 

This  report  documents  the  research  and  development  effort  for 
design  and  documentation  of  the  AN/TSQ-73  using  the  Ada  pro¬ 
gramming  language  (MIL-STD-1815) . 

BACKGROUND 

The  Army  is  currently  developing  an  Ada  compiler  and  associ¬ 
ated  support  tools  as  part  of  its  efforts  to  implement  the 
Ada  language.  As  a  part  of  this  Ada  development  effort,  the 
Army  is  sponsoring  separate  Ada  programs  to  gain  Ada  system 
design  experience  for  use  in  developing  a  curriculum  and 
materials  to  use  Ada  as  a  system/program  design  language 
and  as  an  implementation  language.  To  acquire  software 


BACKGROUND  (continued) 

design  experience  using  Ada,  two  contractors  were  selected  to 
develop  software  design  methodologies  based  upon  the  Ada 
language.  The  results  of  the  two  contractual  efforts, 
which  included  this  contract,  will  be  used  as  inputs  to  a 
training  program  for  potential  Ada  users. 


SCOPE 

This  report  describes  the  contractual  efforts  for  the  period 
of  twelve  months,  July  1,  1981  to  June  30,  1982.  A  synopsis 
of  project  tasks  and  technical  findings  is  contained  »  hin 
the  report  with  detailed  amplification  for  the  follow  r 
areas: 

a.  Training  of  personnel. 

b.  Selection  of  a  design  methodology. 

c.  Validation  of  the  design  methodology. 

d.  Application  of  the  design  methodology  to  the  redesign 
of  AN/TSQ— 73  system. 

e.  Use  of  automated  tools  to  redesign  the  AN/TSQ-73  system. 

f.  Use  of  Ada  as  a  system  design  language  (SDL)  and  a  pro¬ 
gram  design  language  (PDL) . 

g.  Schedule. 

h.  Documentation. 

Products  which  resulted  from  this  effort  are  provided  in 
Appendices  to  this  report. 


PROJECT  TASKS  AND  SCHEDULE 


The  project  tasks  and  schedules  defined  the  contractual 
effort  over  a  period  of  twelve  months  between  July  1,  1981 
and  June  30,  1982.  The  major  tasks  included  a  work  plan, 
training,  development  of  a  software  design  methodology,  redesign 
of  the  AN/TSQ-73,  coding,  and  the  associated  documentation. 


WORK  PLAN 


The  work  plan  documented  Control  Data 1 s  approach  and  rationale 
in  the  performance  of  the  research  and  development  effort. 

The  work  plan  covered  four  phases  -  definition  phase,  design 
phase,  programming  phase  and  summation  phase  -  and  included 
the  following  information: 

a.  Description  of  the  approach  and  rationale  employed. 

b.  Phase  organization. 

c.  Tasks  and  subtasks. 

d.  Milestone  charts. 

e.  Project  staffing  which  included: 

-  job  descriptions 

-  educational  and  professional  synopsis  on  project 
personnel 

-  rationale  for  specific  career  types 

f.  Work  apportionment  plan. 

The  plan  was  followed  and  found  to  be  adequate  for  the 
twelve  month  effort. 

TRAINING 

The  three  types  of  training  which  were  given  to  all  project 
personnel  were  orientation,  formalized  instruction,  and 
informal  training.  The  prime  objectives  for  all  types  of 
training  were  standardization  of  project  familiarization 
and  enhancement  of  specific  disciplines.  A  brief  description 
of  the  different  types  of  training  given  in  support  of  the 
project  follows: 

a.  Orientation  Training  -  the  orientation  included  an 
overview  of  the  project  and  identification  of  the 
unique  aspects  of  the  project. 

b.  Formalized  Instruction  -  this  training  was  classroom 
structured  and  addressed  three  specific  areas:  Design 
Methodology,  Ada  programming  language,  and  Missile 
Minder  System  introduction. 


TRAINING  (continued) 


c.  Informal  Training  -  basically,  this  type  of  training 
is  reinforcement  instruction.  It  enabled  project 
members  to  expand  their  newly  acquired  skills  through 
practical  application  by  designing,  developing,  and 
coding  of  small  segments  of  the  Missile  Minder  System. 

DESIGN  METHODOLOGY 

The  approach  that  was  taken  to  construct  a  system  design 
methodology  was  based  on  lessons  learned,  analytical  studies 
and  successful  practices  in  the  rapidly  emerging  field  of 
software  engineering.  The  following  key  principles  which 
are  somewhat  interdependent,  form  the  foundation  for  the 
evolved  software  system  design  methodology: 

a.  Life  Cycle  View  -  systems  evolve  through  various  stages 
from  requirements  to  maintenance.  Precision  and  account¬ 
ability  should  be  emphasized  in  the  early  stages. 

b.  Levels  of  Abstraction  and  Isolation  of  Detail  -  systems 
should  be  clearly  representable  at  different  conceptual 
levels.  Users  desiring  a  high  level  view  of  the  system 
should  not  be  distracted  by  lower  level  details. 

c.  Finite  Human  Capability  -  all  techniques  (steps)  must 
aim  to  keep  the  design  within  the  constraints  of  human 
understanding . 

d.  Graphical  Communications  -  a  great  deal  of  information 
can  be  easily  and  accurately  communicated  through  the 
use  of  graphics. 

e.  Automated  Techniques  -  should  enhance  the  limited  human 
design  capability  and  increase  design  productivity. 

f.  Human  Communications  -  the  role  of  documentation  is  to 
foster  human-to-human  communications  and  prevent  computer 
errors. 

g.  User  Friendliness  -  the  user  should  feel  comfortable  in 
learning  and  using  the  techniques  and  automated  tools. 


2.3  DESIGN  METHODOLOGY  (continued) 

h.  Simplicity  -  technique.  3hould  be  easy  to  learn  and 
their  proper  utilization  effectively  communicated. 

The  above  principles  shaped  the  design  methodology  which  was 
shown  as  three  phases  and  eight  techniques  (Table  1-1) . 

2.4  DESIGN  METHODOLOGY  VALIDATION 

The  objectives  of  the  validation  effort  were  to  validate 
and  recommend  improvements  to  the  proposed  design  methodology. 
The  validation  task  was  based  upon  the  principles  described 
in  Paragraph  2.3  above,  and  upon  the  following  guidelines: 

a.  Support  a  design  process  which  includes  concurrent 
hardware  design  and  software  design. 

b.  Utilize  the  concept  of  levels  of  abstraction. 

c.  Support  clear  and  concise  descriptions  and  communications 
of  the  design  in  graphic  tools  wherever  possible. 

d.  Support  automated  tools  to  free  human  designers  from 
tedious  and  painstaking  representation  of  their  design 
constructs . 

The  methodology  approach  for  the  validation  task  was  to  take 
a  vertical  slice  of  the  Remote  Communications  function  of  the 
AN/TSQ-73  and  apply  the  design  methodology,  following  the 
eight  steps  identified  in  Table  1-1.  The  AN/TSQ-73  redesign 
phase  also  supports  the  conclusions  of  the  validation  team 
which  are  summarized  below. 

a.  The  proposed  design  methodology  supports  the  self-imposed 
goals  and  objectives. 

b.  The  proposed  design  methodology  supports,  but  does  not 
force,  a  top-down  approach. 

c.  The  coding  phase  should  be  expanded  for  further  evaluation. 

d.  The  use  of  automated  tools  was  invaluable  and  should  be 
enhanced. 
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TECHNIQUES 

System  Entity  Diagram  (SED) 

System  Design  Language  (SDL) 

Data  Flow  Diagram  (DFD) 

Data  Dictionary  (DD) 

Structure  Charts  (SC) 

Program  Design  Language  (PDL) 

Complexity  Measure  (CM) 

Structured  Programming  (SP) 

a.  The  system  entity  diagram  allows  for  functional  decomposition  of 
the  system  at  the  top-level. 

b.  The  system  design  language  generates  Ada-based  textual  represen¬ 
tation  of  the  system  functions. 

c.  The  data  flow  diagrams  are  graphic  representations  of  the  software 
system. 

d.  The  data  dictionary  serves  as  a  central  repository  for  complete, 
unambiguous  data  definitions  and  process  descriptions. 

e.  The  structure  charts  are  used  to  graphically  establish  program 
units,  identify  hierarchy,  and  exchange  of  data. 

f.  The  program  design  language  captures  the  detailed  structure  by 
detailed  design  based  upon  the  Ada  programming  language. 

g.  The  complexity  measure  is  derived  from  a  program's  control  flow 
and  applied  to  the  program  design  to  determine  the  complexity  of 
the  design. 

h.  Structured  programming  is  employed  when  writing  Ada  code  for 
comprehension  and  maintenance  of  the  code. 


PHASES 

'j  System 
l  Design 
[  Phase 

}  Software 
Design 
Phase 


Programming 

Phase 


Table  1-1  -  System  Design  Methodology 
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MISSILE  MINDER  REDESIGN  TASK 


The  AN/TSQ-73  was  redesigned  and  coded  in  accordance  with 
the  techniques  of  the  methodology  described  above.  The 
techniques  were  applied  to  the  AN/TSQ-73  based  on  the 
following  guidelines: 

a.  The  AN/TSQ-73  system  specifications  MIS-19501C  and 
MIS-10297J  were  used  as  prime  requirement  documents 
for  the  system.  The  system  specifications  were 
supplemented  by  product  specifications  for  further 
delineation  of  requirements  when  necessary. 

b.  Design  deviated  from  the  existing  specification 
design  where  improvements  could  be  made  or  restruc¬ 
tured  for  the  Ada  architecture. 

c.  Design  is  not  constrained  by  the  existing  AN/TSQ-73 
hardware  conf igurat ion . 

d.  The  design  phase  included  only  a  sufficient  level 
of  design  to  validate  the  methodology. 

e.  The  subfunction  coded  was  selected  by  the  Government 
for  the  detailed  program  design  and  coding  using  the 
Ada  language. 

f.  No  attempt  was  made  to  determine  the  adequacy  of  Ada 
in  satisfying  AN/TSQ-73  processing  requirements.  This 
limitation  resulted  from  the  use  of  interpreter/trans¬ 
lator  for  program  coding  and  validation. 

g.  The  subfunction  selected  was  related  to  Target  Control 
for  design  to  the  lowest  level,  programmed  in  executable 
code  using  Ada,  and  verified  with  a  limited  scenario 
for  that  function. 

h.  The  design  was  limited  to  the  battalion  level  con¬ 
figuration. 

The  design  began  by  reorganizing  the  functionality  present 
in  the  currently  deployed  system.  The  reorganization  revealed 
four  major  independent  functional  areas  which  are  numbered  in 
accordance  with  methodology  requirements. 


MISSILE  MINDER  REDESIGN  TASK  (continued) 

•  Command  and  Control  (1.0) 

•  Target  Control  (2.0) 

•  Remote  Communication  (3.0) 

•  Radar  Communication  (4.0) 

The  major  functional  areas  were  subsequently  decomposed  to 
allow  subsequent  levels  of  detail  to  be  organized.  This 
functional  decomposition  was  captured  in  graphic  format  by 
the  system  entity  diagrams  and  in  textual  format  by  the 
system  design  language. 

The  system  design  language  was  based  upon  these  guidelines: 

a.  Utilized  Ada  packages  to  represent  collections  of 
logically  related  system  activities.  The  items 
identified  in  any  given  package  should  be  logically 
independent  from  those  represented  in  other  packages. 

b.  Utilized  Ada  procedures  and  functions  to  represent 
system  activities  which  appear  to  be  sufficiently 
distinct  to  act  as  stand-alone  units,  but  at  the 
same  time,  dependent  upon  other  stand-alone  units 
to  accomplish  a  more  global  activity. 

c.  Utilized  Ada  tasks  to  represent  activities  which 
can  provide  services  to  other  program  units  in  a 
concurrent  fashion. 

d.  Utilized  names  and  numbering  structure  provided  in 
the  SED  to  provide  accountability  and  traceability. 

The  software  design  phase  followed  the  system  design  phase 
and  consisted  of  the  development  of  data  flow  diagrams,  data 
dictionary,  and  structure  charts.  The  data  flow  diagrams 
(bubble  diagrams)  defined  information  flow  at  a  level  which 
included  input/output,  processes,  and  storage.  The  data 
dictionary  defined  the  information  in  the  data  flow  diagrams 
in  clear,  unambiguous  terms.  Using  the  data  flow  diagram 
and  data  dictionary,  the  structure  chart  superimposes  the 
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information  from  these  previous  steps  into  hierarchical 
program  units  that  can  be  designed  in  the  programming 
phase.  The  last  phase,  the  programming  phase,  an  Ada- 
based  program  design  language,  complexity  measurement, 
and  source  code  was  generated.  It  was  clear  that  more 
research  is  needed  to  derive  the  optimum  format  for  the 
Ada  PDL  to  differentiate  it  from  the  Ada  code.  There 
was  difficulty  experienced  by  project  members  in  not 
writing  the  entire  code  at  the  PDL  level.  It  was  also 
clear  that  more  research  is  needed  for  an  enhanced  com¬ 
plexity  measure  to  take  advantage  of  Ada ' s  unique  features 
(strong  typing,  tasking) . 

The  application  and  use  of  the  methodology  was  supported 
in  the  validation  effort  and  the  subfunction  effort.  Per¬ 
haps  the  greatest  advantage  is  in  the  area  of  system  design 
based  upon  Ada  as  a  system  design  language.  The  design  was 
relatively  easy  to  follow  since  it  provided  a  logical  se¬ 
quence  from  broad  requirements  to  detailed  design.  The 
design  process  also  demonstrated  the  need  for  automated 
tools,  development  of  a  hardware  design  methodology,  early 
hardware/software  trade-off  decisions,  and  the  need  for 
simulation/modelling  at  the  system  level  due  to  today's 
vast  technology  base. 

2.6  DOCUMENTATION 

The  documentation  produced  within  the  contract  follows: 

a.  Work  plan  which  documents  Control  Data's  approach  and 
rationale  for  the  performance  of  the  contract. 

b.  Ada  System  Designer's  Guide  (Appendix  B)  which  defined 
the  procedures  to  be  used  in  the  development  of  the 
software  design  methodology. 

c.  Design  plan  which  described  the  research  and  develop¬ 
ment  methods  to  provide  a  top  level  design  and  docu¬ 
mentation  of  a  large  scale  software  system. 
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DOCUMENTATION  (continued) 


d.  Validation  report  which  was  an  informal  report  documenting 
the  validation  of  the  methodology. 

e.  Monthly  reports  which  provided  the  status  of  the  program. 

f.  Final  report  which  documented  the  results  of  the  research 
and  development  for  the  design  and  documentation  of  the 
AN/TSQ-73  system. 

g.  Program  listings. 

3.0  TECHNICAL  FINDINGS 

The  significant  technical  findings  are  provided  for  four 
major  areas  as  follows: 

a.  Design  methodology  utility. 

b.  Ada  language  utility. 

c.  Project  team  factors. 

d.  Educational  considerations. 

3.1  DESIGN  METHODOLOGY  UTILITY 

The  system  design  methodology  developed  during  this  period 
is  applicable  to  the  system  and  software  design  phases  for 
embedded  computers.  Further,  a  high  degree  of  confidence 
has  been  developed  that  the  constructs  of  the  Ada  language 
can  be  used  for  the  entire  design  process,  including  system 
design.  Ada  can  serve  as  both  a  system  design  language  and 
a  program  design  language.  The  use  of  the  design  methodology 
provided  significant  conclusions  which  included: 

a.  The  system  entity  diagrams  and  the  system  design  language 
can  be  used  in  parallel. 

b.  Automation  of  all  techniques  allows  faster  production, 
more  efficient  change,  cleaner  documentation  and  a 
framework  for  reliability  checking  and  product  visibility. 

c.  The  methodology  provided  for  traceability  from  require¬ 
ments  to  code. 
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DESIGN  METHODOLOGY  UTILITY  (conclusions) 


d.  The  structured  design  techniques  were  compatible  with 
the  detailed  design  of  the  software. 

e.  The  Ada-based  program  design  language  provided  the 
design  with  significant  power  which  Ada  provided  in 
the  areas  of  abstraction. 

3.2  ADA  LANGUAGE  UTILITY 

Ada  language  constructs  were  used  as  a  system  design  language 
and  program  design  language.  The  system  design  language  is 
a  part  of  the  overall  system  design  process  and  acts  as  the 
initial  techniques  before  functions  are  allocated  to  hard¬ 
ware  or  software.  The  program  design  language  is  used  during 
the  software  design  phase.  The  utility  of  each  is  discussed 
in  the  following  subparagraphs. 

3.2.1  UTILITY  OF  ADA  AS  A  SYSTEM  DESIGN  LANGUAGE 

The  SDL,  resulting  from  a  number  of  evolutionary  changes, 
provided  the  capability  of  defining  system  functional 
requirements.  In  addition,  the  SDL: 

a.  Provided  for  human  understanding  (users,  developers, 
managers)  of  system  requirements. 

b.  Provided  system  information  for  hardware/software 
trade-off  evaluations  and  succeeding  design  phases. 

c.  Provided  system  information  for  management  decisions. 

d.  Provided  for  system  accountability. 

e.  Provided  for  system  consistency. 

f.  Provided  for  ripple-effect  tracing. 

g.  Provided  for  increased  productivity  through  automation. 

h.  Provided  a  primary  working  system  document. 
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UTILITY  OF  ADA  AS  A  PROGRAM  DESIGN  LANGUAGE 


The  design  of  program  units  for  the  AN/TSQ-73  Missile  Minder 
System  used  an  Ada-like  program  design  language  to  facilitate 
the  final  Ada  code.  As  such,  the  program  design  language 
capitalized  on  the  design  work  encapsulated  in  the  SDL 
description,  data  flow  diagrams,  and  the  structure  charts. 

The  programming  design  completes  the  first  step  of  the  pro¬ 
gramming  phase  and  constitutes  the  requirements  for  each 
program  unit.  The  final  step  of  the  programming  phase  was 
the  coding. 

During  the  AN/TSQ-73  redesign  effort,  especially  in  the 
functional  areas  of  target  control,  the  Ada  concepts  proved 
beneficial.  Special  emphasis  was  placed  on  those  constructs 
which  promote  readability  and  facilitate  program  reliability 
and  maintenance.  The  code  produced  appears  to  be  easily 
readable  and  understandable  as  well  as  maintainable. 

3.3  PROJECT  TEAM  FACTORS 

The  following  factors  were  considered  during  the  process  of 
assembling  the  project  team: 

a.  Level  of  education. 

b.  Experience. 

c.  Past  performance. 

The  individuals  chosen  were  required  to  have  the  capability 
to  participate  in  a  team  environment  where  the  collective 
expertise  possessed  by  the  team  could  be  used  to  overcome  the 
shortcomings  of  any  one  individual. 

In  the  selection  of  career  types,  the  following  prerequisites 
were  used: 

a.  Knowledge  of  two  or  more  hiqh  order  programming  languages. 

b.  Coding  experience. 

c.  Familiarity  with  the  basic  concepts  of  large  scale  soft¬ 
ware  systems. 
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d.  Some  system  design  experience. 

e.  Demonstrated  communications  ability. 

The  selection  of  this  depth  and  level  of  experience  provided 
the  necessary  levels  of  career  types  to  fulfill  project 
requirements . 

INSTRUCTIONAL  ISSUES 

Three  elements  of  the  project  were  identified  to  require 
formalized  instruction.  They  were  design  methodology 
(Structured  Analysis/Structured  Design) ,  Ada  Programming 
Language,  and  Missile  Minder  System  (AN/TSQ-73)  Indoctrin¬ 
ation.  From  this  base,  a  level  of  understanding  developed 
from  which  all  project  members  increased  their  degree  of 
expertise. 

All  formalized  instruction  followed  typical  lesson  plans 
and  course  outlines.  The  length  of  instruction  for  each 
course  was  forty  (40)  hours  with  the  exception  of  the  Missile 
Minder  Indoctrination  which  was  twenty-four  (24)  hours.  The 
forty  hour  courses  were  restricted  to  twenty-four  hours  of 
stand-up  instruction  with  the  remaining  sixteen  hours  allo¬ 
cated  to  workshop  sessions  and  small  group  discussions. 

Reinforcement  documentation  was  available  for  all  three  sub¬ 
jects  to  facilitate  problem  solution  and  research  efforts. 
Formalized  instruction  provided  a  standardized  base  of  ex¬ 
pertise,  although  it  was  by  no  means  all  inclusive.  Extensive 
research  and  supplementary  reading  were  required  by  each 
individual  to  obtain  more  information  and  knowledge  on 
specific  subjects.  This  approach  allowed  each  team  member 
to  supplement  his/her  knowledge  for  particular  needs. 


CONCLUSIONS 


The  following  conclusions  resulted  from  the  redesign  of  the 

AN/TSQ-73: 

a.  The  Ada  language,  serving  in  the  multiple  roles  of  a 
system  design  language,  implementation  language,  pro¬ 
gram  design  language,  can  support  a  cohesive  system 
design  methodology. 

b.  The  Ada  language  will  require  substantially  more 
training  than  previous  programming  languages. 

c.  The  system  design  methodology  techniques  can  be  auto¬ 
mated,  therefore,  a  need  exists  for  further  development 
of  automated  design  tools. 

d.  Timing  constraints  of  the  Ada  language  require  further 
evaluation. 

RECOMMENDATIONS 

The  following  recommendations  are  submitted: 

a.  An  automated  design  system  for  the  total  design  process 
be  developed  based  upon  Ada  as  a  design  language. 

b.  The  entire  tracking  sequence  of  the  AN/TSQ-73  be  pro¬ 
grammed  in  Ada  and  results  evaluated  aqainst  a  set  of 
representative  target  reports  to  determine  the  adequacy 
of  Ada  in  a  time  dependent  system. 

c.  A  user's  guide  be  developed  and  published  as  a  part  or 
as  an  adjunct  to  MI*L-STD-1815. 

d.  The  system  design  process,  based  upon  Ada,  be  expanded 
to  include  the  hardware  design  including  simulation/ 
modelling  and  CAD. 

e.  The  configuration  management  process  be  re-evaluated  to 
permit  development  of  the  specifications  as  a  single 
baseline  based  upon  the  Ada  language. 

f.  A  set  of  software  management  techniques  be  developed  to 
act  as  a  production  control  mechanism. 
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PART  II 

TECHNICAL  REPORT 

PURPOSE 

This  report  documents  the  research  and  development  effort 
for  the  design  and  documentation  of  a  large  scale  system 
using  the  Ada  programming  language  (MIL-STD-1815) .  The 
system  is  the  Missile  Minder  System  AN/TSQ-73  as  authori¬ 
zed  by  Contract  DAAK80-81-C-0107.  The  report  contains 
activities  and  findings  in  the  performance  of  the  project. 
These  activities  and  findings  include  adequacy  of  design 
methods  used  in  the  design  of  the  AN/TSQ-73  system,  system 
design  issues,  Ada  language  issues,  and  the  career  types 
required  for  the  system  design. 

BACKGROUND 

The  Ada  language  has  been  chosen  as  the  DOD  common  program¬ 
ming  language.  The  Army  is  currently  developing  an  Ada 
compiler  and  associated  support  tools  as  part  of  its  effort 
to  implement  the  Ada  language.  The  compiler  effort  is  being 
directed  by  CENTACS,  USA  CECOM,  and  will  be  hosted  on  the 
VAX  11/780  system  with  code  generators  for  the  VAX,  PDP  11/70 
and  selected  target  environments.  Follow-on  efforts  willt 
rehost  the  compiler  as  well  as  provide  additional  generators. 
In  addition,  CENTACS  is  sponsoring  the  implementation  of  an 
Ada  translator  that  is  intended  solely  as  a  training  aid 
and  not  for  production  use.  The  translator  is  hosted  on 
and  is  targetted  to  the  VAX. 

The  goals  of  the  Ada  program  design  project  are  to  gain  Ada 
system  design  experience  for  use  in  developing  a  curriculum 
and  materials  for  training  in  using  Ada  as  a  system/program 
design  language  and  as  an  implementation  language.  To  ac¬ 
quire  design  issues  utilizing  Ada,  two  contractors  were 
selected  to  develop  design  methodology  based  upon  the  Ada 
language.  The  results  of  this  effort  will  be  used  as  inputs 
to  a  training  program  for  potential  Ada  users.  The 
Government  also  initiated  a  contractual  design  monitoring 


BACKGROUND  (continued) 

effort  separate  from  this  contractual  effort,  but  parallel 
to  it.  The  intent  of  this  adjunct  effort  is  to  extract 
and  obtain  information  regarding  design  methods  and  approaches 
used,  types  of  documentation  found  to  be  most  useful,  career 
types  required  and  backgrounds  of  the  personnel  involved  in 
the  various  aspects  of  the  design,  adaptability  of  certain 
Ada  features  to  particular  functions  of  the  system  being 
designed,  the  training  period  and  process  required  to  allow 
the  design  personnel  to  effectively  use  Ada,  and  the  identifi¬ 
cation  of  the  Ada  viewpoint  needed  to  execute  the  various 
job  tasks.  This  information  will  assist  in  identifying  and 
outlining  the  educational  materials  and  courses  that  will  be 
required  to  teach  future  designers  and  programmers  how  to  use 
the  Ada  language  effectively  for  large  embedded  computer 
systems. 

The  initiative  for  the  Ada  education  and  training  plans  comes 
from  the  system  design  area  and  the  post-deployment  software 
support  area.  Greater  control  over  the  progression  from  sys¬ 
tem  requirements  to  the  allocation  of  specific  functions  to 
a  software  module  is  required  as  computer  systems  become 
larger  and  more  complex.  Use  of  Ada  during  the  development 
phase  should  improve  management  capability,  but  expertise  at 
the  system  design  level,  where  system  architecture  is  developed 
in  response  to  system  requirements,  must  be  generated.  There¬ 
fore,  the  Ada  program  design  project  approach  is  to  redesign 
the  software  architecture  capturing  functional  requirements 
and  system  interface  requirements  using  Ada  as  a  system 
design  language  and  as  an  implementation  language,  finally 
coding  one  subfunction  of  the  redesigned  system. 

SCOPE 

The  final  report  summarizes  progression  in  the  accomplishment 
of  the  twelve-month  contractual  effort  for  the  redesign  and 
documentation  of  a  large  scale  software  system  (AN/TSQ-73) 
using  the  Ada  programming  language. 
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The  report  describes  the  contractual  efforts  for  the  period  of 
twelve  months,  July  1,  1981  to  June  30,  1982.  A  synopsis  of 
project  tasks  and  technical  findings  is  provided  within  the 
report  with  detailed  amplification  for  the  following  areas: 

a.  Training  of  personnel. 

b.  Selection  of  a  design  methodology. 

c.  Validation  of  the  design  methodology. 

d.  Application  of  the  design  methodology  to  the  redesign 
of  AN/TSQ-73  system. 

e.  Use  of  automated  tools  to  redesign  the  AN/TSQ-73  system. 

f.  Use  of  Ada  as  a  system  design  language  (SDL)  and  a 
program  design  language  (PDL) . 

g.  Schedule. 

h.  Documentation. 

Products  which  resulted  from  this  effort  are  provided  in 
Appendices  to  this  report. 


PROJECT  TASKS  AND  SCHEDULE 


WORK  PLAN 

The  work  plan  documented  Control  Data's  approach  and 
rationale  for  the  performance  of  the  research  and  devel¬ 
opment  effort  utilizing  the  Ada  high  order  language  for 
the  design  and  documentation  of  a  large  scale  software 
system.  The  work  plan  was  divided  into  six  sections 
which  described  the  following  information: 

a.  Description  of  the  approach  and  rationale  employed. 

b.  Phase  organization. 

c.  Tasks  and  subtasks. 

d.  Milestone  charts. 

e.  Project  staffing  which  included: 

Job  descriptions. 

-  Educational  and  professional  synopsis  on  project 
personnel. 

Rationale  for  specific  career  types. 

f.  Work  apportionment  plan. 

Three  phases  and  a  summation  phase  as  shown  in  Figure  2-1 
were  followed  in  the  accomplishment  of  contractual  require¬ 
ments.  Within  these  phases  are  six  major  tasks.  These 
tasks  are  briefly  discussed  in  the  following  subparagraphs. 

a.  Work  Plan  (Task  1.0) 

Based  upon  the  input  as  contained  in  Control  Data's 
proposal,  the  work  plan  identified  the  individual 
tasks,  schedule  of  accomplishment,  and  deliverable 
contractual  products. 

b.  Training  (Task  2.0) 

This  task  familiarized  all  project  personnel  with 
project  requirements  and  intended  objectives.  For¬ 
malized  instruction  was  provided  in  system  design 
methodology,  Ada  programming  language,  and  the  Missile 
Minder  System. 
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WORK  PLAN  (continued) 
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2.2 


c.  Design  Methodology  (Task  3.0) 

This  task  established  a  system  design  methodology  that 
was  used  in  conjunction  with  the  Ada  high  order  lan¬ 
guage  . 

d.  Design  Methodology  Validation  (Task  4.0) 

The  task  of  validation  of  the  methodology  was  accom¬ 
plished  by  designing  and  coding  a  small  portion  of 
the  Missile  Minder  System.  Design  and  code  reviews 
were  conducted  to  detect  and  subsequently  correct 
discrepancies  in  the  design  methodology. 

e.  Missile  Minder  System  (Task  5.0) 

This  task  included  the  high  level  definition  of 
criteria  for  logical  selection  and  allocation  of 
system  functions  and  detailed  design  and  coding. 

The  task  included  a  preliminary  design,  detailed 
design,  and  selected  portions  for  coding. 

f .  Documentation  (Task  6.0) 

The  documentation  task  involved  the  writing,  corre¬ 
lation,  and  production  of  deliverable  products.  The 
documentation  products  were  the  work  plan,  draft  and 
final  design  plan,  final  report  and  source  code. 

TRAINING 

The  three  types  of  training  which  were  given  to  all  project 
personnel  were  orientation,  formalized  instruction,  and 
informal  training.  The  prime  objectives  for  all  types  of 
training  were  standardization  of  project  familiarization 
and  enhancement  of  specific  disciplines.  A  brief  descrip¬ 
tion  of  the  different  types  of  training  given  in  support 
of  the  project  follows: 

a.  Orientation  Training:  The  orientation  included  an 
overview  of  the  project  and  identification  of  the 
unique  aspects  of  the  project. 
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TRAINING  (continued) 

b.  Formalized  Instruction:  This  training  was  classroom 
oriented  and  addressed  three  specific  areas:  design 
methodology,  Ada  programming  language,  and  Missile 
Minder  System  indoctrination.  Amplifying  information 
on  each  of  these  subjects  is  contained  in  Section  3.4. 


c.  Informal  Training:  Basically,  this  type  of  training 
provided  reinforcement  and  enhancement  for  the  formal 
instruction.  It  enabled  project  members  to  expand 
their  newly  acquired  skills  by  practical  application 
by  designing,  developing,  and  coding  of  small  segments 
of  the  Missile  Minder  System.  The  informal  training 
was  supported  by  extensive  research  and  supplementary 
reading  by  team  members. 

DESIGN  METHODOLOGY  DEVELOPMENT 

The  design  methodology  definition  task  established  a  system 
design  methodology  to  be  utilized  in  conjunction  with  the 
Ada  programming  language.  An  additional  requirement  was 
for  the  system  design  methodology  to  be  compatible  with 
large  scale  software  system  construction.  The  following 
subsections  discuss  the  rationale  .for  selecting  the  meth¬ 
odology,  the  eight  techniques  which  compose  the  methodology, 
and  alternate  methodologies  which  were  examined. 
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RATIONALE  FOR  SELECTING  METHODOLOGY 

The  approach  that  was  taken  to  construct  a  system  design  v-'_: 

methodology  was  based  on  analytical  studies  and  successful 
practices  in  the  rapidly  emerging  field  of  software  engineering.  T1”. 
The  following  key  principles  which  are  somewhat  interdependent, 
form  the  foundation  for  the  evolved  software  system  design 
methodology:  ^ 

a.  Life  Cycle  View  -  Systems  evolve  through  various  stages 
from  requirements  to  maintenance.  Precision  and  account¬ 
ability  should  be  emphasized  in  the  early  stages. 

b.  Levels  of  Abstraction  and  Isolation  of  Detail  -  Systems 
should  be  clearly  representable  at  different  conceptual 
levels.  Users  desiring  a  high  level  view  of  the  system 
should  not  be  distracted  by  lower  level  details. 
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RATIONALE  FOR  SELECTING  METHODOLOGY  (continued) 

c.  Finite  Human  Capability  -  All  techniques  (steps)  must 
aim  to  keep  the  design  within  the  constraints  of 
human  under standing. 

d.  Graphical  Communications  -  A  great  deal  of  information 
can  be  easily  and  accurately  communicated  through  the 
use  of  graphics. 

e.  Automated  Techniques  -  Should  enhance  the  limited  human 
design  capability  and  increase  design  productivity. 

f.  Human  Communications  -  The  role  of  documentation  is  to 
foster  human- to-human  communications  and  prevent  com¬ 
puter  errors. 

g.  User  Friendliness  -  The  user  should  feel  comfortable  in 
learning  and  using  the  techniques  and  automated  tools. 

h.  Simplicity  -  Techniques  should  be  easy  to  learn  and 
their  proper  utilization  effectively  communicated. 

Thus,  these  key  principles  shaped  the  system  design  method¬ 
ology  and  are  reflected  in  the  techniques  utilized.  Figure 
2-2  illustrates  the  adherence  of  the  proposed  techniques 
of  the  software  system  design  methodology  with  the  stated 
guiding  principles. 
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SYSTEM  DESIGN  METHODOLOGY  TECHNIQUES 

The  key  principles  discussed  in  Paragraph  2.3.1,  form 
the  foundation  upon  which  the  methodology  rests.  This 
section  presents  the  eight  individual  techniques 
which  are  the  methodology's  key  components.  Refer  to 
Appendix  B  for  a  comprehensive  explanation  and  application 
of  the  methodology.  The  techniques  serve  as  creative  aids 
for  system  development  in  three  phases:  (1)  System  Design 
Phase,  (2)  Software  Design  Phase,  and  (3)  Programming  Phase. 

The  techniques  perform  purposeful  activity  with  their 
respective  output  representing  boundable  products.  As 
such,  the  system  design  phase  is  composed  of  two  boundable 
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Figure  2-2  -  Basic  Principles/Design  Technique  Matrix 
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2.3.2  SYSTEM  DESIGN  METHODOLOGY  TECHNIQUES  (continued) 

products:  (1)  System  Entity  Diagrams,  and  (2)  System  Design 
Language  production.  The  software  design  phase  is  composed 
of  three  boundable  products:  (1)  Data  Flow  Diagrams,  (2) 

Data  Dictionary,  and  (3)  Structure  Charts;  and  the  Programming 
Phase  also  has  three  boundable  products:  (1)  Program  Design 
Language,  (2)  Complexity  Measure,  and  (2)  Structured  Pro¬ 
gramming.  Figure  2-3  illustrates  the  three  phases  of  system 
development,  major  activities  of  these  phases,  and  resulting 
boundable  products. 


The  initial  technique  utilized  is  the  System  Entity  Diagram. 
Graphical  in  nature,  the  system  entity  diagram  allows  for 
the  functional  decomposition  of  the  system  at  the  highest 
levels.  The  approach  results  in  the  system's  major  func¬ 
tions  (entities)  being  partitioned  into  respective  levels 
of  detail.  One  of  the  immediate  advantages  of  this  technique 
is  that  it  affords  the  user  with  an  early  view  of  the  system 
composition,  and  establishes  an  audit  scheme  for  accountability, 
visibility,  and  project  scheduling  and  control. 

Supporting  the  system  entity  diagram  is  the  system  design 
language,  the  second  technique.  The  purpose  of  the  system 
design  language  is  to  generate  an  Ada-based  textual  repre¬ 
sentation  of  the  system  functions.  The  overall  structure 
of  the  system  will  be  reflected  at  an  early  stage  through 
utilization  of  Ada  constructs.  The  joint  information  captured 
by  the  system  entity  diagram  and  the  system  design  language 
concludes  the  system  design  phase  and  is  input  for  hardware/ 
software  trade-offs. 


rv; 


Since  the  scope  of  the  contractual  effort  emphasized  soft¬ 
ware  system  redesign,  the  methodology  continued  only  on 
the  software  side.  The  software  design  phase  utilizes  the 
data  flow  diagram,  the  data  dictionary,  and  structure  charts. 
The  first  technique  employed  is  the  data  flow  diagrams, 
which  are  graphic  representations  of  the  software  system. 
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PHASE  I  ACTIVITY  PRODUCT 
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SYSTEM  DESIGN  METHODOLOGY  TECHNIQUES  (continued) 

They  model  the  system  in  terms  of  input  data,  output  data, 
stored  data,  and  transformations  of  data.  In  support  of 
the  data  flow  diagram  is  the  data  dictionary  and  structure 
chart.  The  data  dictionary  serves  as  a  central  repository 
for  complete,  unambiguous  data  definitions  and  process 
descriptions.  The  structure  charts  are  used  to  graphically 
establish  program  units,  identify  hierarchy,  and  data 
exchanged . 

The  programming  phase  begins  with  the  Ada-based  program 
design  language.  The  purpose  of  the  program  design  lan¬ 
guage  is  to  capture  detailed  structure  by  detail  design 
yet  allow  for  a  flexible  range  of  coding  expressiveness. 

A  complexity  measure  derived  from  a  program's  control  flow 
can  be  applied  to  the  program  design  language  to  estimate 
logical  weight.  Those  program  units  above  a  set  quantitative 
value  can  be  re-examined  for  simpler  alternatives.  Finally, 
structured  programming  is  employed  when  writing  the  actual 
Ada  code  for  comprehension  and  maintenance  purposes. 

ALTERNATIVE  METHODOLOGIES 

The  system  design  methodology  evolved  for  the  project  was 
briefly  described  in  the  previous  section.  It  has  been 
significantly  influenced  by  the  established  camp  of  struc¬ 
tured  analysis  and  structured  design  formalized  by  Myers, 
Constantine  and  Yourdon.  The  common  theme  includes  the 
concepts  of  levels  of  abstraction,  graphical  representa¬ 
tions,  facility  for  automating  the  chosen  techniques  and 
other  principles  described  previously.  In  addition,  and 
in  recognition  of  the  unique  requirements  of  embedded 
tactical  computer  systems  and  the  advanced  features  of  the 
Ada  programming  language,  other  compatible  techniques  have 
been  added. 
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ALTERNATIVE  METHODOLOGIES  (continued) 


During  the  design  methodology  study  segment  of  this  con¬ 
tract,  a  number  of  other  design  methods  were  reviewed. 

A  detailed  description  of  these  methodologies  can  be 
found  in  the  design  plan,  a  deliverable  under  this 
contract.  The  reviewed  methodologies  include: 

a.  Jackson  Methodology 

b.  Warnier/Orr 

c.  SADT 

d.  PSL/PSA 

e.  HOS 

f .  SREM 

VALIDATION 

The  validation  of  the  design  methodology  was  begun  in  mid 
September,  1981,  and  ended  at  the  end  of  February,  1982. 
The  effort  took  place  over  a  period  of  5.5  months  for  a 
total  of  17.5  man-months.  The  following  subparagraphs 
detail  the  results  of  the  validation  effort. 


OBJECTIVES 

The  objectives  of  the  validation  effort  were  to  validate 
and  recommend  improvements  to  the  proposed  design  methodology 
that  was  created  by  Control  Data's  Shrewsbury  Facility  in 
the  redesign  of  the  Missile  Minder  AN/TSQ-73  System.  The 
key  principles  of  the  evolving  methodology  were  utilized 
by  the  validation  team  and  are  reiterated  below: 

a.  Life  Cycle  View  -  systems  evolve  through  various  stages 
from  requirements  to  maintenance. 

b.  Levels  of  Abstraction  and  Isolation  of  Detail  -  the 


ability  to  clearly  describe  systems  at  different  con 
ceptual  levels.  Users  desiring  a  high  level  view  of 
the  system  should  not  be  distracted  by  lower  level 
details. 
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OBJECTIVES  (continued) 

c.  Finite  Human  Capability  -  all  techniques  (steps)  must 
aim  to  keep  the  design  within  the  constraints  of 
human  understanding. 

d.  Graphical  Communications  -  a  great  deal  of  information 
can  be  easily  and  accurately  communicated  through  the 
use  of  graphics. 

e.  Automated  Techniques  -  should  enhance  the  limited  human 
design  capability  and  increase  design  productivity. 

f.  Human  Communications  -  the  role  of  documentation  is  to 
foster  human-to-human  communications. 

g.  User  Friendliness  -  the  user  should  feel  comfortable 
in  learning  and  using  the  techniques  and  automated 
tools. 

h.  Simplicity  -  so  that  the  techniques  can  be  properly 
utilized  and  effectively  communicated. 

Based  on  the  above  key  principles,  the  design  methodology 

musts 

a.  Support  a  design  process  which  includes  concurrent 
hardware  design  and  software  design. 

b.  Utilize  the  concept  of  levels  of  abstraction. 

c.  Support  clear  and  concise  descriptions  and  communi¬ 
cations  of  the  design  in  graphic  tools  wherever  possible. 

d.  Support  automated  tools  to  free  human  designers  from 
tedious  and  painstaking  representation  of  their  design 
constructs . 


In  addition,  the  following  questions  were  asked  for  answers 
based  upon  the  team's  validation  experience: 

a.  Do  the  techniques  represent  the  proper  level  of 
abstraction?  Is  there  too  much  or  too  little  of 
a  conceptual  leap  between  the  sequential  applica¬ 
tion  of  the  techniques? 
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OBJECTIVES  (continued) 


b.  Are  the  techniques  complete  enough  to  fully  represent 
their  level  of  abstraction? 

c.  Are  the  automated  tools  beneficial  and/or  necessary  for 
the  methodology?  Are  there  any  recommendations  for  the 
automated  tools? 

d.  Is  the  System  Designer's  Guide  descriptive  enough  to 
properly  utilize  the  techniques?  Are  there  any  recom¬ 
mendations  to  improve  the  System  Designer's  Guide? 

e.  What  is  Ada's  strength  as  a  System  Design  Language  (SDL)? 

f.  What  is  Ada's  weakness  as  a  System  Design  Language  (SDu) ? 
Are  there  any  additional  thoughts  on  Ada  as  an  SDL? 

g.  Are  there  any  difficulties  in  proceeding  from  the  System 
Entity  Diagram  (SED)  to  the  System  Design  Language  (SDL) 
to  the  Data  Flow  Diagram  (DFD) ? 

h.  How  to  you  know  when  to  apply  Ada's  concept  of  TASK, 
PACKAGE,  PROCEDURE,  FUNCTION  and  EXCEPTION?  Other  Ada 
concepts  utilized? 

2.4.2  PROPOSED  ADA  SYSTEM  DESIGN  METHODOLOGY  FOR  VALIDATION 

The  proposed  Ada  design  methodology  included. eight  design 
techniques  as  defined  in  the  System  Designer's  Guide.  These 
techniques,  outlined  below,  are  defined  to  be  the  beginning 
of  the  design  effort. 

a.  System  Entity  Diagram  (SED)  -  is  used  to  graphically 
represent  the  first  three  abstract  levels  of  the  sys¬ 
tem  being  designed.  The  three  levels  of  abstraction 
are  facility,  subfacility,  and  function. 

b.  System  Design  Language  (SDL)  -  is  used  to  textually 
represent  the  system  being  designed.  The  graphic 
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2.4.2  PROPOSED  ADA  SYSTEM  DESIGN  METHODOLOGY  FOR  VALIDATION (continued) 

third  level  SEDs  are  translated  into  free-form  English 
statements  formed  from  a  subset  of  the  Ada  language. 

The  SDLs  may  be  decomposed  beyond  the  third  level  where 
no  SEDs  exist. 


NOTE:  The  SED  and  SDL  techniques  are  performed  prior 

to  hardware/software  implementation  and  as  such, 
represent  a  functional  description  of  the  system. 
The  remaining  methodology  steps  decompose  only 
the  software  portion  of  the  system. 

c.  Data  Flow  Diagram  (DFD)  -  is  a  graphic  representation  of 
the  system  in  terms  of: 

•  Input  data 

•  Output  data 

•  Stored  data 

•  Significant  intermediate  data  forms 

•  Data  transformations 

d.  Data  P  ctionary  (DP)  -  is  a  textual  representation  of 
any  one  of  the  following: 

•  Data  Definitions 

•  Module  descriptions  with  action  definitions 
(pseudo  code) 

•  Process  specifications  with  actio  definitions 
(pseudo  code) 

•  Undefined  names 
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2.4.2  PROPOSED  ADA  SYSTEM  DESIGN  METHODOLOGY  (continued) 

e.  Structure  Chart  (SC)  -  is  a  graphic  representation  that: 

•  Partitions  the  system  described  by  the  Data  Flow 
Diagrams  and  Data  Dictionary  into  a  hierarchy  of 
modules,  each  of  which  is  viewed  as  performing 
a  well-defined  and  programmable  function  in  the 
system. 

•  Establishes  the  means  and  the  direction  of  commu¬ 
nication  between  modules. 

f .  Program  Design  Language  (PPL)  -  is  a  textual  represen¬ 
tation  of  the  structure  charts  into  program  units 
utilizing  Ada  constructs  as  program  pseudo  code. 

g.  Complexity  Measure  (CM)  -  is  a  graphic  representation 
of  the  complexity  of  the  PDL. 

h.  Structured  Programming  (SP)  -  is  the  Ada  coding  of  the 
PDL  into  compilable  code. 

The  design  of  the  system  follows  a  top-down  approach  as  shown 
in  Figure  2-4.  The  system  design,  which  is  the  top-level 
of  the  structure,  consists  of  system  entity  diagrams  (SED) 
and  the  system  design  language.  The  lower  level,  the  soft¬ 
ware  design,  follows  the  remaining  hierarchical  levels  to 
the  lowest  level  which  is  the  executable  code. 

Although  not  stated  in  this  version  of  the  System  Designer's 
Guide,  the  methodology  provided  for  accountability,  consis¬ 
tency,  and  ripple-effect  tracing  with  a  numbering  scheme. 

At  the  initial  methodology  step,  the  SEDs  form  a  tree  struc¬ 
ture  with  its  first  level  of  abstraction  numbered  1.0,  2.0, 
3.0,  4.0,  etc.  The  second  level  of  abstraction  begins  with 
numbers  1.1  through  l.n  until  the  level  is  completed  to  4.1 
through  4.n.  The  third  level  begins  1.1.1,  etc.,  until  4.n.n 
Thus,  utilizing  this  numbering  scheme,  the  line  of  parental 
heritage  is  defined  as  well  as  the  level  of  abstraction. 
Example,  abstract  1.1.1  (level  three)  is  the  offspring  of 
abstract  1.1  (level  two)  which  is  the  offspring  of  abstract 
1.0  ( level  one) . 
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Figure  2-4  -  Proposed  Design  Methodology  Structure 

for  Validation 


II-2-15 


2.4.3  DESIGN  METHODOLOGY  PROCESS 

A  vertical  slice  of  the  Missile  Minder  AN/TSQ-73  system 
Remote  Communications  was  selected  for  validation.  Since 
the  vertical  slice  had  not  been  redesigned,  the  validation 
team  served  as  both  designers  and  validators.  As  the  design 
progressed,  the  eight  methodology  steps  shown  in  Figure  2-4 
were  identified  as  three  distinct  phases.  Those  three  dis¬ 
tinct  phases.  Figure  2-5  ,  were  followed  in  the  redesign 
of  the  AN/TSQ-73,  paragraph  2.5  of  this  report.  The  coding 
phase,  hence,  has  been  renamed  the  programming  phase.  The 
AN/TSQ-73  redesign  phase  also  supports  the  conclusions 
reached  by  the  validation  team  in  most  areas. 

2. 4. 3.1  SYSTEM  ENTITY  DIAGRAM 

The  word  "system"  is  defined  in  Webster's  Collegiate  Dictionary 
as,  "a  regularly  interfacing  or  interdependent  group  of  items 
forming  a  unified  whole".  The  term  was  applied  to  the  AN/TSQ- 
73  system  to  mean,  "The  AN/TSQ-73  system  is  a  combination  of 
hardware,  software,  and  operator  interaction  required  to  meet 
the  objectives  and  mission  of  the  AN/TSQ-73". 


The  validation  team  applied  these  definitions  to  the  SEDs  and 

the  SDLs  of  the  AN/TSQ-73  Remote  Communications  subsystem. 

Structured  walkthroughs  were  used  throughout  the  validation 

effort.  The  System  Designer's  Guide  stated  that:  (1)  only 

the  three  highest  system  abstract  levels  are  required  for  the 

SED,  and  (2)  the  SEDs  are  totally  completed  before  beginning 

the  next  methodology  step,  i.e. ,  SDL.  Control  Data's  Struc- 

% 

tured  Analysis/Structured  Design  (SASD)  graphics  packages 
were  used  to  produce  Remote  Communications  SEDs.  The  vali- 
datation* team  findings  were: 

a,  A  design  methodology  requiring  exactly  three  abstract 
SED  levels  is  too  restrictive  and  provided  insufficient 
AN/TSQ-73  system  information. 
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Figure  2-5  -  Top-Down  Design  Methodology  Structure 

(Revised) 
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SYSTEM  ENTITY  DIAGRAM  (continued) 

b.  In  the  case  of  Remote  Communications,  a  fourth,  fifth 
and  sometimes  sixth  SED  level  were  produced  to  provide 
a  clear  AN/TSQ-73  system  picture. 

c.  The  number  of  abstract  SED  levels  required  to  express 
a  given  system  is  dependent  upon  the  magnitude  and 
complexity  of  the  system  being  designed.  Therefore, 

n  number  of  SED  levels  should  be  permitted.  To  accom¬ 
plish  n  number  of  abstract  levels,  a  different  graphic 
scheme  would  be  required.  A  possible  solution  is 
shown  in  Figure  2-6. 


As  seen  from  that  example,  the  numeric  level  of  abstraction 
would  form  the  inner  line  of  the  graphic.  Thus,  a  two-lined 
graph  could  be  used  to  represent  ten  levels  of  abstraction 
and  a  three- lined  graph  |f  function”  could  be  used  to  repre¬ 
sent  one  hundred  levels  of  abstraction. 

d.  It  was  far  more  productive  to  complete  only  one  or  two 
SED  levels  before  constructing  the  corresponding  SDL  and 
back  to  the  SED  decomposition  again  than  to  complete  the 
entire  SED  partitioning  before  beginning  the  SDL  (explained 
more  fully  iater  in  the  report) . 

e.  Control  Data's  SASD  graphic  tools  were  not  designed  for 
the  SED,  but  rather  the  structure  chart  tools  was  adapted 
to  meet  SED  requirements.  Such  as: 

•  The  ability  to  graphically  illustrate  n  number  of 
SED  levels  did  not  exist.  Although  for  this  pro¬ 
ject,  a  maximum  of  six  abstraction  levels  was 
determined  to  be  sufficient. 

•  The  number  of  characters  per  graphic  description 

is  limited  which  resulted  in  the  use  of  many  symbol 
identifiers  being  abbreviated  or  partially  omitted. 

•  The  amount  of  SED  information  per  screen  or  printed 
page  is  limited.  This  limitation  may  be  hardware 
oriented  since  a  high  resolution  graphic  terminal 
was  not  utilized  in  producing  these  graphics. 
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2. 4. 3.1  SYSTEM  ENTITY  DIAGRAM  (continued) 

f.  The  System  Designer's  Guide  could  be  improved  by  the 
use  of  a  clearly  defined  SED  illustration. 

g.  The  system's  SEDs  do  not  stand  by  themselves  in  pro¬ 
viding  a  system  description,  but  require  clarification 
through  an  individual  or  the  next  technique  (SDL)  in 
the  design  methodology. 

h.  The  SEDs  do  not  provide  a  functional  value  in  graphi¬ 
cally  illustrating  a  system's  functions  at  various 
abstract  levels.  Reference  Appendix  C  for  Remote 
Communications  SEDs . 

2. 4. 3. 2  SYSTEM  DESIGN  LANGUAGE 

Unlike  the  SED  technique,  the  initial  System  Designer's  Guide 
limited  SDL  definition  resulted  in  several  false  starts  by 
the  validation  team.  This  eventually  led  to  the  validation 
team  redefining  the  SDL  technique. 

The  system  definition  was  applied  by  the  validation  team  to 
the  initial  SDL  technique.  The  conclusions  were  that  the 
SDL  contained  several  weak  points:  accountability  and  consis¬ 
tency  will  be  weakened  and  may  eventually  be  lost  if  the 
SDL  does  not  start  at  the  highest  SED  level;  the  utilization 
of  only  four  Ada  constructs  nullifies  much  of  the  power  of 
Ada;  system  design  concerns  such  as  throughput,  concurrency, 
capacity,  growth,  environment,  etc.,  were  not  addressed  by 
the  initial  SDL  definition. 

Based  on  these  findings,  it  was  determined  that  each  SED 
graphic  symbol  would  be  described  in  the  following  categories 
based  on  an  object-oriented  design. 

a.  Entity 

b.  Object 

c.  Operation 

d.  Environment 

e.  Activity 
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2. 4. 3. 2  SYSTEM  DESIGN  LANGUAGE  (continued) 

The  validation  team  attempted  to  complete  the  Remote  Commu¬ 
nication  SDLs  with  the  new  definition,  but  found: 

a.  It  was  impractical  or  impossible  to  express  high 
level  system  abstractions  with  this  technique. 

b.  Lower  level  system  abstraction  (fifth  or  sixth  level) 
were  easily  expressed  in  this  form,  but  did  not  pro¬ 
vide  sufficient  system  information. 

The  validation  team  was  then  given  the  additional  task  of 
defining  the  new  SDL  approach.  This  was  accomplished  over 
an  elapsed  time  period  of  two  plus  months.  The  current  SDL 
has  evolved  through  several  iterations  of  the  AN/TSQ-73 
Remote  Communications.  With  each  iteration,  adjustments 
and  additions  to  the  SDL  were  made.  The  SDLs  were  recorded 
on  two  systems  (the  VAXs  at  Fort  Monmouth  and  Control  Data's 
CYBERNET  system)  using  each  system's  text  editor. 

The  validation  team  redefined  the  SDL  in  terms  of  what 
objectives  of  an  SDL  are,  and  what  comprises  an  SDL. 

The  objectives  of  the  SDL  are: 

a.  To  be  suitable  for  human  (developers,  users  and  managers) 
understanding . 

b.  To  provide  system  input  for  hardware /software  trade-off 
evaluations  and  succeeding  design  techniques. 

c.  To  provide  system  input  for  configuration  management 
decisions . 

d.  To  provide  for  system  accountability. 

e.  To  provide  for  system  consistency. 

f;  To  provide  for  system  ripple-effect  tracing. 
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g.  To  provide  for  increased  productivity  through  automation. 

h.  To  be  utilized  as  the  primary  working  system  document. 

The  SDLs  are  Ada-based  textual  representations  of  system 

functions  which  are  composed  of : 

a.  System  objective (s) . 

b.  System  requirements  and  capabilities. 

c.  System  capacities. 

d.  System  constraints. 

e.  System  exception  handling. 

f.  System  entities,  subentities,  their  relationships, 
and  execution  type  (serial,  concurrent) . 

g .  System  control . 

h.  System  data  flow. 

i.  System  environment. 

j .  Operator  interactions . 

Many  questions  have  been  answered  by  the  SDL,  but  more 

questions  still  need  to  be  answered: 

a.  Ada  purists  versus  Ada  generalists  questions.  How  exact 
or  how  close  must  Ada  as  a  SDL  follow  Ada's  programming 
language  requirements?  Don't  forget  users  or  managers! 
Are  semi-colons  and  underscore  characters  required  or 
desirable?  Can  functions,  procedures  and  tasks  be  repre¬ 
sented  in  a  single  SDL  statement  to  indicate  both  a 
declaration  and  usage? 
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b. 


The  use  of  Ada  within  the  SDL  enters  the  "gray  area"  arena 
on  the  ambiguous  use  of  procedures.  This  ambiguous  use 
centers  on  the  double  use  of  Ada's  procedures  to  indicate 
both  a  system  "PROCEDURE  TSQ-73"  and  a  low  level  system 
function  "PROCEDURE  ENCODE  MESSAGE  HEADER". 


c.  How  do  you  conceptually  decide  which  Ada  construct  is 
more  appropriate  (task,  package,  procedure)? 


d.  How  do  you  express  Ada  constructs  for  different  or 
multiple  processors? 

c** 

e.  How  do  you  express  concurrency  at  a  high  abstraction 
level? 


f.  To  what  detail,  if  any,  should  an  SDL  describe  inter 
faces  between  modules? 
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The  Data  Flow  Diagrams  (DFD)  are  the  third  technique  in  the 
design  methodology.  The  DFDs  provide  a  graphic  representation 
of  input  data,  output  data,  stored  data,  significant  inter¬ 
mediate  data  forms  and  data  transformations.  The  validation 
team  first  designed  a  small  segment  of  Remote  Communications 
using  Control  Data's  SASD  automated  tools.  The  DFDs  were 
easily  transformed  from  their  respective  SDLs.  Accountability 
and  consistency  were  maintained  by  retaining  the  system  design's 
numbers.  Only  the  lower  DFD  levels  (below  the  existing  SED 

levels)  required  original  work.  The  DFD  technique  was  then 
validated  with  the  following  findings: 

a.  The  DFD  technique  is  a  viable  tool  to  clearly  illustrate 
the  various  items  mentioned  above. 

b.  The  only  suggestion  to  improve  the  system  designer's  guide 
would  be  to  provide  a  complete  DFD  example  illustrating 
the  various  abstract  levels. 
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2. 4. 3. 4  DATA  DICTIONARY 

The  Data  Dictionary  (DD)  is  the  fourth  methodology  technique 
or  step.  The  DDs  provide  textual  representation  of  data 
definitions,  module  descriptions  with  action  (pseudo  code) 
definitions,  process  specifications  with  (pseudo  code) 
definitions,  and  undefined  names.  Control  Data's  automated 
data  dictionary  tool  was  used  to  record  and  produce  the  DDs 
for  a  chosen  subset  of  Remote  Communications.  The  data  dic¬ 
tionary  was  to  be  produced  from  the  DFDs .  The  transition 
from  DFDs  to  DDs  was  much  more  difficult  than  the  transition 
from  SDLs  to  DFDs. 

The  findings  of  the  validation  team  are: 

a.  The  data  dictionary  is  a  technique  to  be  utilized  from 
the  SDL  through  structured  programming.  In  order  to 
complete  all  the  required  DD  definitions,  the  SDL,  DFD , 
SC,  PDL  and  SP  were  referenced. 

b.  The  DD  is  a  vital  technique  used  in  defining  the  system's 
software  functions  and  data. 

c.  There  is  some  redundancy  in  the  data  dictionary's  pseudo 
code  and  the  code  produced  for  the  methodology's  SDL  and 
PDL. 

d.  The  system  designer's  guide  could  be  improved  in  the 
following  areas: 

•  Definitions  of  data  flow,  transformations,  etc. 

•  The  use  of  an  example  in  explaining  the  DD  process. 

•  The  methodology  should  view  the  data  dictionary  as 
a  technique  that  begins  with  the  SDL  and  ends  with 
structured  programming . 

e.  Control  Data's  automated  data  dictionary  tool  was 
invaluable  in  providing: 
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•  Input  error  list  generation. 

•  Cross-reference  report. 

•  Cross  check  report. 

•  Flagging  of  undefined  data  definitions. 

•  Flagging  of  recursively  defined  definitions. 

2. 4. 3. 5  STRUCTURE  CHARTS 

The  Structure  Charts  (SC)  are  the  fifth  methodology  technique 
or  step.  The  SCs  provide  a  graphic  representation  that  par¬ 
titions  the  system  described  by  the  DFDs  and  DD  into  a  hier¬ 
archy  of  modules,  each  of  which  is  viewed  as  performing  a 
well-defined  function  and  establishes  the  means  and  the 
direction  of  communication  between  modules.  The  structure 
charts  were  to  be  produced  from  the  DFDs  and  DDs .  The  tran¬ 
sition  from  DFDs  and  a  partial  DD  to  SCs  was  smooth.  Control 
Data's  automated  structure  chart  tool  was  used  to  record  and 
produce  the  SCs  for  the  Remote  Communications  segment.  The 
findings  of  the  validation  team  are: 

a.  The  structure  charts  were  finished  prior  to  the  completion 
of  the  data  dictionary.  The  minimum  amount  of  information 
that  was  added  to  the  data  dictionary  as  a  result  of  the 
SCs  would  also  be  found  in  the  PDL. 

b.  There  is  informational  redundancy  between  the  structure 
charts  and  the  other  design  methodology  techniques : 

•  The  sysfeflT'partitioning  functions  performed  by  the 
SCs  are  also  performed  by  the  SDLs,  DFDs,  and  PDL. 

•  The  module  interface  requirements  performed  by  the 
SCs  are  also  performed  by  the  DFDs. 

c.  A  question  of  whether  the  structure  chart  is  a  viable 
technique  or  not  within  the  design  methodology  exists. 
Based  upon  the  validation  effort,  the  structure  charts 
are  a  duplication  of  design  functions  performed  by  the 


II-2-25 


2. 4. 3. 5  STRUCTURE  CHARTS  (continued) 

other  design  techniques.  Therefore,  the  question  of 
should  the  SC  be  eliminated  must  be  raised  or  is 
there  something  possibly  missing  from  the  methodology's 
definition  of  structure  charts.  This  technique  needs 
to  be  re-evaluated. 

2. 4. 3. 6  PROGRAM  DESIGN  LANGUAGE 

The  Program  Design  Language  (PDL)  is  the  sixth  methodology 
technique  or  step.  The  PDL  provides  a  textual  representation 
of  the  structure  charts  into  program  units  utilizing  Ada 
constructs  as  program  pseudo  code.  The  Army's  VAX  system  was 
used  to  record  the  PDL  for  a  segment  of  Remote  Communications. 
The  findings  of  the  validation  team  are: 

a.  Although  the  structure  charts  were  initially  used  to 
produce  the  PDL,  the  same  information  was  located  in 
the  DFDs  which  were  utilized  for  the  final  PDL. 

b.  Information  within  the  PDL  was  used  as  additional  input 
(data  definitions)  to  the  data  dictionary. 

c.  In  most  areas  of  the  PDL,  the  structured  programming  was 
completed  before  it  was  realized  that  this  had  occurred. 
The  remaining  portions  of  the  PDL  require  almost  no 
effort  to  become  code.  Why  or  how  this  occurred  can 
only  be  surmized  that  the  segment  selected  for  validation 
coding  was  possibly  at  the  PDL  step  when  the  data  flow 
diagrams  were  completed.  It  may  be  that  the  selected 
validation  coding  was  too  small  of  a  segment.  The  possi¬ 
bility  exists  that  the  validation  group's  decomposition  of 
DFDs  included  too  much  detail.  Would  this  be  a  common 
occurrence  or  was  just  a  fluke  occurrence?  Could  this 
occur  to  a  large  number  of  modules  within  the  AN/TSQ-73? 

d.  The  system  designer's  guide  could  provide  more  definition 
in  explaining  the  PDL  process. 
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The  complexity  measure  (CM)  is  the  seventh  methodology  tech¬ 
nique  or  step.  The  CM  provides  a  graphic  representation  of 
the  complexity  of  the  PDL.  Unfortunately,  this  step  would 
not  be  validated  due  to  the  ease  of  the  PDL  to  structured 
programming  that  occurred  during  the  validation  effort. 
Several  discussions  were  held  concerning  this  technique  and 
the  concensus  was  that  the  benefits  of  the  complexity  measure 
would  also  be  beneficial  as  an  earlier  technique  to  be  used 
within  the  methodology.  The  CM  could  also  be  utilized  at 
the  SDL  and/or  DFD  step  where  the  effects  of  a  modification 
would  be  less  dramatic  and  expensive. 

2. 4. 3. 8  STRUCTURED  PROGRAMMING 

The  structured  programming  (SP)  is  the  Ada  coding  of  the  PDL 
into  compilable  code.  As  stated  earlier  in  the  report,  this 
was  completed. 

2.4.4  VALIDATION  FINDINGS 

The  findings  and  suggestions  of  the  validation  team  in  their 
critique  of  the  proposed  system  design  methodology  for  large 
scale  systems  development  are: 

a.  The  proposed  system  design  methodology  appears  to  have 
achieved  most  of  its  self-imposed  goals  and  objectives. 

b.  The  proposed  system  design  methodology  supports  top- 
down  design,  yet  no  single  technique  or  step  forces  the 
individual  to  use  top-down  design.  Whether  the  meth¬ 
odology  requires  a  technique  modification  or  addition  to 
enforce  top-down  design  or  the  existing  methodology  co¬ 
erces  top-down  design  through  the  various  techniques  and 
peer  walkthrough  evaluations  is  not  known. 

c.  Redundancy  between  and  among  the  methodology's  techniques 
should  be  minimized.  Potential  redundant  candidates  are: 

•  The  Pseudo  code  in  the  data  dictionary. 

•  The  structure  chart  techniques  (after  its  re-evalu¬ 
ation)  . 


II-2-27 


VALIDATION  FINDINGS  (continued) 

d.  The  coding  development  phase  (PDL,  CM  and  SP)  should 
be  revalidated  with  a  large  segment  of  the  AN/TSQ-7"3 . 

e.  The  use  of  automated  tools  for  the  design  and  validation 
of  the  AN/TSQ-73  proved  to  be  invaluable  and  productive 
within  the  areas  of  SED,  DFD ,  DD,  and  SC.  The  role  of 
automated  tools  should  be  enhanced  within  the  design 
methodology. 

f.  As  viewed  by  the  validation  team,  the  proposed  methodology 
would  be  utilized  as  follows: 

(1)  The  system  development  process  begins  with  the 
SDLs  statement  of  the  system's  (specifications) 
objectives,  requirements,  capabilities,  etc. 

The  developers  functionally  partition  or  decompose 
the  system  into  various  levels  of  abstraction. 

After  every  one  or  two  abstraction  levels,  the 
developers  would  request  the  computer  aided 
design  (CAD)  system  to  automatically  produce 
the  SEDs  for  the  system  being  developed.  The 
data  dictionary  is  begun  and  automatically  updated 
throughout  the  entire  development  process.  The 
developers  may  request  the  automated  application 
of  the  complexity  measure  to  the  system  design 
phase.  These  tools,  SEDs,  DD  reports  and  the  CM, 
would  assist  the  developers  through  this  iterative 
process . 

After  a  number  of  iterative  decompositions  and 
structured  walkthroughs,  the  system  paritioning 
process  is  completed.  The  number  of  abstract 
levels  required  will  be  dependent  upon  the  system 
being  developed.  It  should  also  be  expected  that 
within  a  specific  system,  the  number  of  abstract 
levels  will  vary. 

Accountability  and  consistency  will  be  maintained 
through  the  SDL  numbering  scheme.  Ripple-effect 
resulting  from  system  modifications  can  be  traced. 
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(2)  An  historical  data  base  is  accessed  by  the  developers 
to  locate  similar  system  functions  that  have  been 
previously  developed  for  other  systems.  If  function¬ 
al  matches  are  located,  a  copy  of  each  function 
(SDL,  PDL,  SP)  is  moved  into  the  developing  system's 
SDL  where  modifications  may  have  to  be  made  to  enable 
incorporation.  The  historical  data  base  would  be 
searched  throughout  the  entire  development  project. 

(3)  The  developing  system  s  SDL  is  enhanced  through  the 
use  of  Ada  constructs .  Ambiguous  system  functions 
will  be  clarified  through  Ada's  exactness.  Additional 
system  decomposition  may  also  occur. 

(4)  Other  techniques  will  ultimately  decide  (from  SDL 
and  other  inputs)  which  functions  of  the  system  will 
be  implemented  in  hardware  and  software.  The  SDL 
will  be  updated  to  indicate  these  decisions.  The 
SDL  may  also  require  modifications  as  a  result  of 
these  decisions. 

(5)  The  software  design  phase  begins  by  expanding  and 
amplifying  the  SDL  towards  a  PDL.  The  data  diction¬ 
ary  is  automatically  updated.  As  the  Ada  enhancement 
process  continues,  the  designers  may  request  the  CAD 
system  to  automatically  produce  the  related  DD  reports, 
the  DFDs ,  and  SCs,  for  the  desired  design  area.  The 
designers  may  also  request  the  automated  application 

of  the  complexity  measure.  Such  tools  would  assist 
designers  in  this  iterative  process. 

(6)  The  final  development  phase  would  be  detailed  Ada 
programming.  This  would  be  developed  from  the 

Ada  PDL.  The  data  dictionary  is  again  automatically 
updated. 
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The  above  suggested  design  methodology  can  be  illustrated 
as  shown  in  Figure  2-7.  The  modification  of  the  design 
methodology  as  suggested  by  the  validation.  team  would 
require  a  Computer  Aided  Design  (CAD)  system  and  DD,  DFDs, 
and  SCs  with  enhanced  meaning.  The  results  would  be: 

a.  A  single  development  language,  Ada,  to  be  utilized 
by  developers,  designers,  and  programmers. 

b.  A  single  baseline  system  which  grows  with  the  system 
development  process. 

As  can  be  seen  by  the  later  changes,  the  design  methodology 
evolved  to  a  level  later  shown  in  Figure  2-9. 
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1  Ada 

2  CAD-built 

3  CAD-generated  developers /designers  request 

4  CAD-applied  upon  developers/designers  request 


Figure  2-7  -  Revised  Design  Methodology  Illustration 
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REDESIGN  OF  THE  AN/TSQ-73  MISSILE  MINDER  SYSTEM  USING 
THE  ADA  DESIGN  METHODOLOGY 


The  AN/TSQ-73  Missile  Minder  System  was  designated  by 
contract  as  the  system  to  be  redesigned  based  upon  the 
Ada  language.  This  section  of  the  report  describes  the 
application  of  the  system  design  methodology  to  the 
redesign  of  the  AN/TSQ-73  Missile  Minder  System.  The 
results  of  this  task  include: 

a.  The -application  of  the  design  methodology  to  include 
the  following  phases: 

•  System  design  phase 

•  Software  design  phase 

•  Programming  phase 

b.  Key  issues. 

c.  Advantages  and  disadvantages  of  the  design  methodology 
as  applied  to  the  AN/TSQ-73  system. 

d.  Rationale  for  change  in  design  methodology. 

e.  Verification/ test  methods  and  results. 

2.5.1  INTRODUCTION 

The  Missile  Minder  AN/TSQ-73  System  is  the  air  defense  command 
and  control  system  (Figure  2-8)  designed  to  coordinate  actions 
of  Hawk,  Improved  Hawk,  and  Nike/Hercules  surface-to-air  missiles 
against  hostile  air  targets.  The  system  is  fielded  in  two 
configurations,  the  group/BDE  level  system  and  the  BN-level 
system.  The  mission  of  each  system  is  as  follows: 

a.  The  mission  of  the  group/BDE  level  system  concentrates 
on  the  air  defense  activities  of  subordinate  BN-level 
systems,  allocation  and  assignment  of  air  defense  resources, 
planning  air  defense  operations,  supervising  the  effec¬ 
tiveness  of  real-time  air  defense  resources,  serving 
as  the  tactical  operations  center  for  group  operations, 
and  interfacing  with  other  group-level  missile  minder 
systems,  and  tactical  command  and  control  systems  of 
other  services. 
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Figure  2-6  -Group/BDE  and  BN  Operational  Configuration 


INTRODUCTION  (continued) 

b.  The  mission  of  the  BN-level  configuration  is  to  control 
the  actual  direction  of  the  air  battle  with  its  execution 
being  directed  at  the  fire  unit  level.  The  BN-level 
system  acquires,  tracks,  identifies  aircraft,  provides 
real-time  threat  evaluation  and  weapons  assignment  for 
hostile  aircraft  engagement,  and  provides  friendly  air¬ 
craft  protection.  A  BN-level  system  can  be  designated 
as  a  master  BN-level  system  when  a  group/BDE- level  system 
is  inoperable  or  non-existent  due  to  local  conditions. 

The  designated  master  BN-level  system  will  provide  the 
interface  to  other  Army  tactical  data  systems  and  tacti¬ 
cal  command  and  control  systems  of  other  military  services 

The  battalion  level  system  was  selected  for  redesign  of  the 
AN/TSQ-73  of  which  one  subfunction  will  be  programmed  to 
the  level  of  executable  code.  The  overall  design  of  the 
AN/TSQ-73  system  has  been  decomposed  and  repartitioned  into 
four  major  functional  areas: 

•  Command  and  control. 

•  Target  control. 

•  Remote  communications. 

•  Radar  communications. 

Target  control  has  been  selected  as  the  area  for  detail 
design,  of  which  two  program  units  -  "smoothing  and  predic¬ 
tion"  will  be  coded. 

The  redesign  of  the  AN/TSQ-73  and  coding  was  affected  by 
the  f o 1 lowing : 

a.  The  AN/TSQ-73  system  specifications  MIS-19501C  and 
MIS-1 0297J  were  used  as  prime  requirements  documents 
for  the  system.  The  system  specifications  were  sup¬ 
plemented  by  product  specifications  for  further 
delineation  of  requirements  when  necessary. 
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b.  Design  deviated  from  the  existing  specification 
where  improvements  could  be  made  or  restruc¬ 
turing  was  necessary  for  the  Ada  architecture. 

c.  Design  was  not  constrainted  by  the  existing  AN/TSQ- 
73  hardware  configuration. 

d.  The  design  phase  included  only  a  sufficient  level 
of  detail  to  validate  the  methodology. 

e.  No  attempt  was  made  to  determine  the  adequacy  of 
Ada  in  satisfying  AN/TSQ-73  processing  requirements. 

This  limitation  results  from  the  use  of  interpreter/ 
translator  for  program  coding  and  validation. 

Although  the  contract  called  for  a  large  scale  system  soft¬ 
ware  design,  the  top-level  system  design  and  some  hardware 
design  was  necessary  to  show  how  the  design  methodology  is 
applicable  to  the  AN/TSQ-73.  Figure  2-9  shows  the  system 
design  methodology  which  is  based  upon  the  Ada  language. 

The  top  level  design  is  shown  at  the  top  of  the  chart  and 
represents  the  system  design  function  described  in  Paragraphs 
2. 5. 2.1  and  2. 5. 2. 2.  The  second  level  of  the  chart  is  the 
software  and  hardware  design  phases  which  are  based  upon  the 
hardware  and  software  trade-offs  normally  conducted  as  a  part 
of  the  hardware  and  software  trade-off  analysis.  The  hardware 
design  was  limited  to  development  of  the  engineering  block 
diagram  of  the  system  (Paragraph  2. 5. 2. 3).  Therefore,  the 
hardware  design  methodology  has  been  omitted.  The  hardware 
and  software  design  is  eventually  completed  and  integrated 
as  a  complete  system. 
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2CAD-built 

3 CAD-generated  developers /designers  request 
4CAD-applied  upon  developers/designers  request 


Figure  2-9  -  System  Design  Methodology 
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The  complexity  measure,  which  is  shown  across  all  phases, 
is  an  area  requiring  further  investigation.  The  complexity 
measure  herein  was  the  McCabe  Complexity  Measure  which  is 
applicable  to  the  software  design. 


The  design  is  based  upon  the  use  of  computer  aided  design 
tools,  but  may  be  accomplished  manually.  However,  the 
manual  method  defeats  the  use  of  automation  to  provide 
accountability  and  traceability,  and  the  elimination  of 
the  drudgery  involved  in  the  detail  design  work. 
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SYSTEM  DESIGN  PHASE 

The  system  design  phase  included  three  subphases: 

a.  Development  of  the  system  entity  diagrams  (SED) 

b.  Development  of  the  system  design  specifications  using 
Ada  as  a  system  design  language  (SDL) 

c.  Hardware /software  trade-off  analysis. 

These  three  subphases  were  adequate  to  develop  the  system 
design  to  the  specification  level,  commonly  known  as  B2 
hardware  and  B5  software  specifications  using  Ada-like 
pseudo  code  and  Ada  constructs .  Although  the  SED  develop¬ 
ment  started  as  a  separate,  independent  phase,  it  actually 
was  completed  in  conjunction  with  the  other  two  phases.  It 
was  more  productive  to  complete  only  one  or  two  SED  levels 
and  then  construct  the  corresponding  SDL.  Upon  completion 
of  the  corresponding  SDL,  the  SED  was  further  decomposed 
and  the  corresponding  SDL  was  prepared.  Although  the  hard¬ 
ware/software  trade-off  analysis  was  limited.  Control  Data 
is  satisfied  that  all  three  subphases  are  dependent  and 
should  be  developed  through  an  iterative  process  to  the 
desired  level. 

The  evolved  design  methodology  lends  itself  to  automation 
which  was  a  major  consideration  in  selecting  each  design 
methodology  technique.  The  various  levels  of  automation 
were  not  determined  since  a  full  complement  of  automatic 
or  computer  assisted  design  tools  were  not  available. 
However,  an  automated  tool  currently  under  development  by 
Control  Data  was  used  for  generation  and  update  of  the  SEDs 
The  design  methodology  which  was  based  upon  the  use  of  the 
tool  limited  the  number  of  functional  levels  to  three.  Thi 
was  far  too  restrictive  for  a  large  system  such  as  the  .AN/ 
TSQ-73.  The  design  plan  expanded  the  decomposition  of 
requirements  to  "n"  level.  Any  fully  developed  automated 
tool  should  support  these  levels. 
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.1  SYSTEM  ENTITY  DIAGRAM  (SEP) 

The  system  entity  diagram  was  produced  using  AN/TSQ-73 
specifications  MIS-19501C  and  MIS-10297J  to  define  the 
system  functional  requirements.  Since  the  SED  involved 
a  learning  process  for  the  system  analyst  and  programmers 
in  the  understanding  of  both  the  design  methodology  and 
the  AN/TSQ-73  system,  its  value  as  a  top-level  structure 
tool  was  well  demonstrated.  The  SED  provided  a  logical 
grouping  of  the  functions  in  a  graphic  form,  easily  read¬ 
able  by  both  the  users,  analysts  and  programmers.  Although 
the  preparation  of  the  SED  was  relatively  easy,  several 
iterations  were  required  to  capture  the  functions.  Table 
2-1  provides  a  list  of  the  hierarchical  SED  entities  and 
Appendix  C  provides  the  completed  SEDs. 

The  SED  was  based  to  a  degree  upon  the  packaging  concept 
of  the  Ada  language.  In  fact,  a  detailed  SED  may  be  even¬ 
tually  defined  in  software  areas  to  reflect  packages,  tasks, 
procedures  and  functions.  In  the  system  design  SDL  tech¬ 
nique,  note  that  the  titles  reflect  the  system  diagram 
and  the  system  entity  numbers  to  provide  traceability  and 
accountability  throughout  the  design. 

The  development  of  the  SEDs  followed  the  processes  listed 
below: 

a.  Identify  the  functions  of  the  AN/TSQ-73  at  the  top 
hierarchical  level.  This  serves  as  a  baseline  for 
further  decomposition  of  functions. 

b.  Develop  subentities  at  the  second,  third  through 
"n"  levels. 

c.  Assign  numbers  to  each  entity  level  beginning  at 
the  top  structure  level  and  continuing  to  the 
lowest  entities.  The  numbers  provide  traceability 
throughout  the  design. 
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1.0 

1 


Table 


COMMAND  AND  CONTROL 


1  General  Operating  System 

1.1.1  System  Bootstrap  Initialization 


1.1. 1.1 
1.1. 1.2 

1.1. 1.3 

1.1. 1.4 

1.1. 1.5 

1.1. 1.6 

1.1. 1.7 


Executes  Initial  Start-Up  Procedures 
Loads  and  Executes  Operating  System 
Initializes  System  Console  Device 
Initializes  System  Log 
Initializes  Remaining  Peripherals 
Initializes  System  Coprocessors 
Loads  and  Executes  System  Command 
Interpreter 


1.1.2  Resource  Management 


1.1. 2.1 

1.1. 2. 2 

1. 1.2.3 

1.1. 2. 4 

1. 1.2.5 

1.1. 2. 6 

1.1.3  Task 


Processor  Management 
Memory  Management 
Interrupt  Management 
Time  Management 
Peripherals  Management 
Coprocessors  Management 

Management 


1.1. 3.1  Task  Characteristics  Manager 


1.1. 3. 1.1 

1.1. 3. 1.2 

1.1. 3. 1.3 

1.1. 3. 1.4 

1.1. 3. 1.5 


Task  Type 
Task  Status 
Task  Priority 
Site  Execution  Location 
Determination 
Critical  Tasks 


1.1. 3.2 

Task 

Scheduling  Policies  Manager 

1. 1.3.3 

Task 

Synchronization  Manager 

1.1. 3.4 

Task 

Invocation 

1.1. 3. 5 

Task 

Suspension 

1.1. 3. 6 

Task 

Resummation 

1.1. 3. 7 

Task 

Termination 

1.1. 3. 8 

Task 

Creation 

1.1. 3. 9 

Task 

Deletion 

4  Task 

Communications 

1. 1.4.1  Low  Level 


1.1. 4. 1.1 


1.1. 4. 1.2 


1.1. 4. 1.3 

1.1.4. 1.4 


Device  Communications  Using 
I/O  Bus 

Device  Communications  Using 
Memory  I/O  Bus 
Intertask  Communications 
Using  Shared  Variables 
Intertask  Communications 
Using  Message  Buffers 


-1  -  Hierarchical  Listing  of  AN/TSQ-73  (page  1  of  7) 


II-2-40 


1.1. 4. 2  High  Level 

1.1. 4. 2.1  Channels 

1.1. 4. 2. 2  Files 

1.1. 4. 2. 3  Intrasystem  Transfers 

1.1.5  Power  Fail/Automatic  Restart 

1.1. 5.1  Power  Fail 

1.1. 5. 2  Automatic  Restart 

1.1.6  Device  I/O  Handlers 

1.1. 6.1  Physical  Device  Interface 

1.1. 6. 2  Physical  to  Logical  Interface  Task 

1.1.6. 3  Logical  Device  Channels 

1.1.7  File  Management 

1.1. 7.1  Data  Structures 

1.1. 7. 2  File  Manager 

1.1. 7. 3  File  Manager  Utilities 

1.1. 7. 4  Files  to  Logical  Device  Channels 

1.1.8  Error  Recovery  and  System  Reporting 

1.1. 8.1  Error  Recovery 

1.1. 8. 2  System  Reporting 

1.1.9  System  Command  Interpreter 

1. 1.9.1  Assembler 

1 . 1 . 9 . 2  Ada  Language 

1.1. 9. 3  Libraries 

1.1. 9. 4  Editors 

1.1. 9. 5  Utilities 

1.1.10  Maintenance  and  Diagnostics  Utilities 

1.1.10.1  Destructive  (Off-Line)  Utilities 

1.1.10.2  Non-Destructive  (On-Line)  Utilities 

1.2  Runtime  Support  Software 

1.2.1  Runtime  Operating  System 

1.2.2  Runtime  System  Library 

1.2.3  Mathematical  Library 

1.2.4  Character  String  Library 

1.2.5  Runtime  On-Line  Debugger 

1.3  Runtime  Initialization 

1.3.1  Loads  Runtime  Support  Software 

1.3.2  Optionally  Loads  On-Line  Debugger 

1.3.3  Loads  User  Application  Library 

1.3.4  Optionally  Loads  System  Exercisor 

1.3.5  Loads  I/O  Message  Interpreter 

1.3.6  Optionally  Opens  Transaction  Message  Log 

1.3.7  Loads  Site  Adaptation 

1.3.8  Loads  Target  Control 

1.3.9  Loads  Remote  Communications 

1.3.10  Loads  Radar  Communications 
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1.4  User  Application  Library 

1.4.1  Transverse  Mercator 

1.4.2  Sterographic  Function 

1.4.3  Slant  Coordinates 

1.4.4  Geographic  Function 

1.5  I/O  Message  Interpreter 

1.5.1  Message  Routing  Manager 

1.5. 1.1  Input  Messages 

1.5. 1.2  Output  Messages 

1.5.2  Display  Update  I/O  Manager 

1.6  Runtime  Termination 

1.6.1  Generate  Termination  Message  to  Local/ 

.  Remote  Users 

1.6.2  Terminates  Radar  Communications 

1.6.3  Terminates  Remote  Communications 

1.6.4  Terminates  Target  Control 

1.6.5  Optionally  Closes  Transaction  Message  Log 

1.6.6  Termination  Options 

1.7  Runtime  System  Exercisor 

1.7.1  Exercisor  Command  Supervisor 

1.7.2  User  Application  Library  Exercisor 

1.7.3  I/O  Message  Interpreter  Exercisor 

1.7.4  Site  Adaptation  Exercisor 

1.7.5  Target  Control  Exercisor 

1.7.6  Remote  Communications  Exercisor 

1.7.7  Radar  Communications  Exercisor 

2 . 0  TARGET  CONTROL 

2.1  Start-Up  Initialization 

2.1.1  Real-Time  Clock 

2.1.2  Initialize  Track  Algorithms 

2.1.3  Initialize  Threat  Evaluation  Algorithms 

2.1.4  Initialize  Weapons  Assignment  Algorithms 

2.1.5  Initialize  Track  Tables 

2.1.6  Sector  Definition 

2.2  Tracking 

2.2.1  IFF/SIF 

2. 2. 1.1  Auto  Beacon  Interrogation 

2. 2. 1.2  Manual  Interrogation 

2. 2. 1.3  Verify  IFF  Code 

2. 2. 1.4  Mode  4  Interrogation 

2. 2. 1.5  Interrogate  Beacon 

2.2.2  Target  Report  Processing 

2.2.3  Track  While  Scan 
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2. 2. 3.1  Correlation  Actions 

2. 2. 3. 1.1 

Computer  Deviation  Vector 

2. 2. 3. 1.2 

Innergate  Correlation 

2. 2. 3. 1.3 

Outergate  Correlation 

2. 2. 3. 1.4 

Non-Auto  Beacon  Correlation 

2. 2. 3. 1.5 

Altitude  Gate  Correlation 

2. 2. 3. 1.6 

Correlation  Score 

I  2. 2. 3. 2  Association  | 

2. 2. 3. 2.1 

Sort  Pairs  by  Track  Category 

2. 2. 3. 2. 2 

Compare  Correlation  Scores 

2. 2. 3. 2. 3 

Merge  Condition  Test 

2. 2. 3. 2. 4 

IFF  Emergency  Test 

2. 2. 3. 2. 5 

Update  Association  Count 

i  2 . 2 . 3 . 3  Smoothing  j 

2. 2. 3. 3.1 

Smooth  Position 

2. 2. 3. 3. 2 

Smooth  Velocity 

2. 2. 3. 3. 3 

Smooth  Altitude 

2. 2. 3. 3. 4 

Detect  Track  Maneuverability 

1  2. 2. 3. 4  Prediction  1 

2. 2. 3. 4.1 

Computer  Assoc  Predicted  Position 

2. 2. 3. 4. 2 

Computer  Non-Assoc  Predicted  Position 

2. 2. 3. 4. 3 

Update  Track  Record 

2.2.4  Track  While  Scan  Utilities 

2. 2. 4.1  Automatic  Initiate  New  Track 

2 . 2 . 4 . 2  Drop  Track 

2. 2. 4. 3  Determine  Track  Quality 

2 . 3  Track  Manager 

2.3.1  Track  Update 

2.3.2  Manage  Tables 

1  2.3.3  Determine  Track  Status  I 

2.3.4  Data  Control 

2. 3. 4.1  Routing 

2. 3. 4. 2  Filtering 

2.3.5  Operator  Switch  Action 

2. 3. 5.1  Operator  Tracking  Actions 

2. 3. 5. 1.1 

Initiate  Tracks 

2. 3. 5. 1.2 

Hook  Display  Element 

2. 3. 5. 1.3 

Update 

2. 3. 5. 1.4 

Enter  Track  Information 

2. 3. 5. 1.5 

Drop  Track 

2.3.5.1 .6 

Change  Mode  of  Tracking 

2. 3. 5. 1.7 

Obtain  Close  Control 

2. 3. 5. 1.8 

Enter  Maneuver  Sensitivity 

2. 3. 5. 1.9 

Enter  Alternate  Track  Number 

2.3.5.1.10 

Enter  Jam  Strobes 

2.3.5.1.11 

Enter  Clutter  Map  Area 

2.3.5.1.12 

Enter  Method  of  Tracking 

2.3.5.1.13 

Challencre  IFF  Modes 
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2. 3.5. 2  Operator  Tactical  Actions 

2. 3. 5. 2.1  Couple/Decouple  Fire  Units 

2. 3. 5. 2. 2  Make  Primary /Secondary  Assignments 

2. 3. 5. 2. 3  Reference/Dereference  Track  for 

Trans 

2. 3. 5. 2. 4  Enter  Fire  Unit  Information 

2. 3. 5. 2. 5  Designate  Display  Elements 

2 . 3 . 5 . 2 . 6  Terminate  Engagements 

2. 3. 5. 2. 7  Accept  Reject  Remote  Site  Commands 

2.4  Counter  Measure  Process 

2.4.1  Jam  Strobe 

2. 4. 1.1  Jam  Strobe  Correlation 

2. 4. 1.2  Jam  Strobe  Association 

2. 4. 1.3  Jam  Strobe  Initiation 

2. 4. 1.4  Jam  Strobe  Update 

2. 4. 1.5  Drop  Jam  Strobe 

2.4.2  Chaff 

2 . 5  Engage  Target 

2.5.1  Threat  Evaluation 

2.5.2  Evaluate  Weapons  Assignment  Score 

2.5.3  Weapons  Assignment 

2.5.4  Monitor  Engagement 

3.0  REMOTE  COMMUNICATIONS 

3 . 1  Communication  Supervisor 

3.1.1  Consume  Internal  Message 

3.1.2  Initialize  Remote  Communication 

3. 1.2.1  Housekeeping 

3. 1.2. 2  Initialize  Communication  Subsystem 

Parameters 

3. 1.2. 3  Initiate  Manage  Message 

3. 1.2. 4  Initiate  Manage  Data  Links 

3.1.3  Manage  Data  Links 

3. 1.3.1  Manage  Data  Link  Status  Table 

3. 1.3. 2  Manage  Protocols 

3.1.4  Manage  Messages 

3. 1.4.1  Outgoing  Messages 

3. 1.4. 2  Incoming  Messages 

3. 1.4. 3  Manage  Message  Buffers  and  Queues 

3.1.5  Manage  Fault  Detection,  Correction  and  Reporting 

3. 1.5.1  Identify  Faults 

3. 1.5. 2  Update  Error  Counters 

3. 1.5. 3  Attempt  Corrective  Action 

3. 1.5. 4  Report  Faults 

3.1.6  Terminate  Remote  Communications 

3. 1.6.1  Build  Termination  Message 

3. 1.6. 2  Start  Terminate  Data  Link 

_ 3 .1.6, 3  Update  Data  Link  Status  Table  _ 
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3 . 1 . 6 . 4  Abort  Data  Link  Manager 

3. 1.6. 5  Abort  Message  Manager 

3. 1.6. 6  Update  Transaction  Message  Log 

3.1.7  Produce  Internal  Message 

3.2  Intrasystem  Transfers 

3.2.1  Get  Intrasystem  Transfers 

3.2.2  Put  Intrasystem  Transfers 

3.2.3  Message  Posting 

3. 2. 3.1  Consumer  Timer 

3 . 2 . 3 . 2  Producer  Timer 


3.3  Communication  Protocols 


3.3.1  TADIL-B  Protocol  Supervisor 

3.3.2  ATDL-1  Protocol  Supervisor 

3.3.3  MBDL  Protocol  Supervisor 


3. 3. 3.1 

3. 3. 3.2 

3. 3. 3. 3 

3. 3. 3. 4 

3. 3. 3. 5 

3. 3. 3. 6 

3. 3. 3. 7 


Consume  Comm  Supervisor  Message 

Initialize  Data  Link 

Transmit  Message 

Receive  Message 

Protocol  Utilities 

Terminate  Data  Link 

Comm  Supervisor  Message  Product 


4 . 0  RADAR  COMMUNICATIONS 


4 . 1  Communication  Supervisor 

4.1.1  Consume  Internal  Message 

4.1.2  Initialize  Radar  Interface  Communication 

4.1.3  Manage  Data  Links 

4 . 1 . 3 . 1  Manage  Data  Link  Status  Table 

4. 1.3. 2  Manage  Protocols 

4.1.4  Manage  Messages 

4. 1.4.1  Message  Supervisor 

4. 1.4. 1.1  Determine  Message  Action 

4. 1.4. 1.2  Select  Highest  Priority  Message 

4. 1.4. 1.3  Post  Transmission  Message  Action 

4. 1.4. 2  Outgoing  Messages 

4. 1.4. 2.1  Select  Highest  Priority  Message 

4. 1.4. 2. 2  Validate  Outgoing  Message 

4. 1.4. 3  Incoming  Messages 

4. 1.4. 4  Internal  Messages 

4. 1.4. 5  Manage  Message  Buffers  and  Queues 

4.1.5  Manage  Fault  Detection,  Correction  and  Reporting 

4. 1.5.1  Identify  Faults 

4. 1.5.2  Update  Error  Counters 

4. 1.5. 3  Attempt  Corrective  Action 

4. 1.5. 4  Report  Faults 

4.1.6  Terminate  Radar  Communication 
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4. 1.6.1  Build  Termination  Message 

4 . 1 . 6 . 2  Start  Terminate  Data  Link 

4. 1.6. 3  Update  Data  Link  Status  Table 

4 . 1 . 6 . 4  Abort  Data  Link  Manager 

4. 1.6. 5  Abort  Message  Manager 

4. 1.6. 6  Update  Transaction  Message  Log 

4.1.7  Product  Internal  Message 

4. 1.7.1  Select  Highest  Priority  Message 

4. 1.7. 2  Dequeue  Message  from  Produce  Internal 

Message  Queue 

4.2  Intrasystem  Transfers 

4.2.1  Get  Intrasystem  Transfers 

4.2.2  Put  Intrasystem  Transfers 

4.2.3  Message  Posting  Timer 

4.3  ATDL-1  Protocol  Supervisor 

4.3.1  Consume  Comm  Supervisor  Message 

4.3.2  Initialize  Data  Link 

4.3.3  Transmit  Message 

4.3.4  Receive  Message 

4.3.5  Protocol  Utilities 

4.3.6  Terminate  Data  Link 

4.3.7  Comm  Supervisor  Message  Product 
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2. 5. 2.1  SYSTEM  ENTITY  DIAGRAM  (SEP)  (continued) 


d.  Enter  system  entity  diagrams  into  data  base  for  update 
and  accountability. 

e.  Update  the  diagram  as  required. 

f.  Place  the  system  entity  diagram  under  configuration 
management  control.  This  will  not  be  accomplished 
until  the  design  using  SDL  is  complete;  i.e.,  the 
system  level  and  the  subsystem  level. 

An  early  statement  above  indicated  that  the  system  entity 
diagram  was  relatively  easy  to  prepare.  This  was  in  part 
as  a  result  of  the  provision  of  AN/TSQ-73  requirements  by 
the  government.  In  practice,  the  system  entity  diagram  is 
a  cumulative  product  based  on  a  thorough  analysis  of  user 
requirements.  The  greatest  benefit  of  the  SED,  perhaps,  is 
that  it  reflects  user  requirements  in  relatively  easy-to-read 
functions.  This  is  especially  true  with  military  personnel 
who  are  oriented  toward  the  use  of  block  and  line  diagrams 
to  reflect  functions.  The  software  designer  found  the  SED 
to  be  especially  useful  because  it  presented  the  overall 
functional  picture. 


The  SED  also  has  significant  disadvantages: 

a.  The  SED  does  not  provide  interfaces  between  entities. 

b.  The  SED  is  a  large  diagram  which  restricts  its  use 
as  a  total  single  picture  of  the  system.  It  must 

be  reviewed  in  segments  which  is  allowed  by  the  auto¬ 
mated  tools. 
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2. 5. 2. 2  DEVELOPMENT  OF  SYSTEM  DESIGN  SPECIFICATIONS 

The  system  design  specifications  were  completed  using  Ada 
as  a  system  design  language  (SDL) .  Application  of  Ada's 
structuring  features  was  based  upon  these  guidelines: 

a.  Utilize  packages  to  represent  collections  of  logically 
related  system  activities.  The  items  identified  in 
any  given  package  should  be  logically  independent  from 
those  represented  in  other  packages. 

b.  Utilize  procedures  and  functions  to  represent  system 
activities  which  appear  to  be  sufficiently  distinct 
to  act  as  stand-alone  units,  but  at  the  same  time, 
dependent  upon  other  stand-alone  units  to  accomplish 
a  more  global  activity. 

c.  Utilize  tasks  to  represent  activities  which  can  pro¬ 
vide  services  to  other  program  units  in  a  concurrent 
fashion. 

d.  Utilize  the  names  and  numbering  structure  provided 

in  the  SED  to  provide  accountability  and  traceability. 

Using  the  above  guidelines,  the  SDL  captured  all  the  func¬ 
tions  necessary  to  define  the  system.  In  comparing  the 
system  design  and  performance  characteristics  with  those 
guidelines  of  MIL-STD-490,  the  conclusion  can  be  reached 
that  Ada  can  be  used  as  a  system  design  language.  At  first 
review,  the  system  design  was  not  readily  apparent  to  the 
casual  reader  although  written  in  English  and  in  narrative 
format  based  upon  Ada-like  pseudo  code.  As  the  design 
further  developed,  it  was  relatively  easy  to  follow  since 
it  provided  a  logical  sequence  from  broad  requirements  to 
detail  design.  The  design  specifications  were  easier  to 
follow  then  the  traditional  A-level,  B-level,  and  C-level 
specifications,  in  that  the  design  provided  a  logical 
sequence  and  avoided  the  duplication  normally  found  between 
levels  of  specifications.  Although  the  logical  steps  in 
the  design  methodology  should  be  followed,  the  SDL  can  be 
used  to  document  the  design  to  the  level  of  executable 
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2. 5. 2. 2  DEVELOPMENT  OF  SYSTEM  DESIGN  SPECIFICATIONS  (continued) 

code.  Therefore,  the  design  methodology  may  be  used  to 
specify  design  of  the  software  to  a  single  baseline. 

The  SDL  above  provides  no  graphic  information.  Therefore, 
the  SDL  should  be  supported  with  graphic  information  to  depict 
the  design,  particularly  interfaces  for  clarity.  First, 
the  hardware  design  section  of  the  system  should  show  the 
partitioning  of  the  hardware  in  graphic  form.  To  provide 
this  capability,  graphic  tools  programmed  in  Ada  should  be 
provided  as  a  part  of  the  system  design  phase. 

2.5. 2. 3  HARDWARE /SOFTWARE  TRADE-OFF  ANALYSIS 

Hardware  and  software  trade-off  anlaysis  in  the  design 
process  was  limited;  however,  the  design  methodology  provides 
a  high  degree  of  decoupling  in  its  design  which,  in  turn, 
provides  a  high  degree  of  flexibility  for  the  design  engineer. 
A  preliminary  analysis  indicates  that  the  hardware  design 
can  be  specified  to  the  B2  level  using  Ada  as  a  design  lan¬ 
guage.  A  shortcoming  exists  in  that  graphic  tools  are 
required  to  generate  the  supporting  graphics  tools,  however, 
the  methodology  techniques  have  the  capability  of  generating 
the  graphic  information  via  on  an  automated  design  system. 

In  the  past,  the  selection  of  design,  both  hardware  and  soft¬ 
ware,  has  to  a  large  extent  resulted  from  the  way  the  user 
defines  his  requirements.  Design  factors  have  included  such 
considerations  as  size,  weight,  constraints,  processing  times, 
response  times,  bench  markings,  permanancy  of  design,  redun¬ 
dancy,  flexibility,  reliability,  etc.  With  the  exception  of 
selected  time  functions  that  can  be  measured,  the  actual  par¬ 
titioning  of  the  design  and  selection  of  the  components  is, 
to  large  degree,  a  judgement  factor  in  the  early  days  of 
design.  The  partitioning  of  hardware  and  software  in  commer¬ 
cial  systems  is  a  lesser  problem  in  that  software  design  is 
based  upon  existing  product  lines.  In  contrast,  embedded 
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military  computer  systems  are  based  upon  militarization  of 
existing  products,  new  designs  and  potentially  the  Military 
Computer  Family.  With  the  liberal  use  of  microprocessors, 
the  partitioning  becomes  an  even  more  critical  issue,  even 
within  the  top-level  design. 

Models  have  been  used  in  the  past,  but  unfortunately,  the 
models  have  been  almost  as  costly  and  time  consuming  as  the 
actual  design  and  fabrication.  Secondly,  the  models  have  been 
application-dependent.  Nevertheless,  this  area  must  be  inves¬ 
tigated  in  more  detail  with  the  goal  being  the  inclusion  of 
the  development  of  automated  simulation /model ling  techniques. 


Although  a  detailed  hardware /software  trade-off  analysis  was 
not  accomplished  as  a  part  of  the  system  design,  some  redesign 
of  the  AN/TSQ-73  was  accomplished  to  provide  a  better  under¬ 
standing  of  the  hardware  and  software  partitioning.  The  design 
also  takes  maximum  advantage  of  Ada's  packaging,  increases  the 
radar  processing  capabilities,  improves  communication  interfaces 
with  several  baud  rates  and  provides  continuity  of  operation 
through  redundancy.  Figure  2-10  is  a  representation  of  the 
redesigned  AN/TSQ-73  engineering  block  diagram  but  does  not  re¬ 
present  a  final  design,  although  this  design  is  considered  an 
improvement  over  the  original  design  and  may  be  fully  imple¬ 
mented  within  the  AN/TSQ-73  shelter.  The  design  provides  a 
number  of  capabilities: 

a.  Judicious  selection  of  components  from  today's  data 
base  will  provide  the  additional  flexibility  for  any 
additional  overhead  and  processing  time,  if  any,  in 
the  use  of  Ada. 


b.  It  enhances  communication  and  improves  error  rate 
through  the  use  of  variable,  selectable  bit  rates 
and  error  detection  correction  schemes.  The  program 
for  accomplishing  this  task  is  a  nart  of  remote  commu¬ 
nication  Ada  package,  which  may  be  implemented  as  firm¬ 
ware  or  software.  The  trend  is  implementation  in  firm¬ 


ware  . 
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HARDWARE/SOFTWARE  TRADE-OFF  ANALYSIS  (continued) 

c.  Multi-radar  inputs  can  be  processed  simultaneously. 
The  target  control  function  in  the  proposed  desicrn 
permits  simultaneous  processing  of  a  multiple  target. 

d.  It  provides  continuity  of  operation  through: 


(1) 

Switching  of  peripherals. 

(2) 

Redundancy  of  CPUs,  memories. 

and  data  channels 

(3) 

Multi-data  channels. 

(4) 

Distributed  real-time  clocks 

and  processing 

functions. 

Multi-power  sources. 

f.  Flexibility  in  election  of  peripherals. 

SOFTWARE  DESIGN  PHASE 

The  software  design  phase  consisted  of  three  steps: 

a.  Development  of  data  flow  diagrams. 

b.  Preparation  of  data  dictionary. 

c.  Structure  charts. 

These  three  subphases  were  easier  to  prepare  as  a  sequence 
than  the  system  design  phase.  However,  some  iterative 
changes  were  necessary  primarily  because  of  the  learning 
process  involved  in  using  the  methodology . 

DATA  FLOW  DIAGRAMS 

The  data  flow  diagrams  were  identified  to  include  these 
four  areas: 

a.  Inputs. 

b.  Transformations  (processes) . 

c.  Storage  areas. 

d.  Outputs. 
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The  data  flow  diagrams  were  developed  to  the  lowest  level 
and  provided  traceability  back  to  system  design  phase  by 
extending  the  numbering  scheme.  The  names  associated  with 
the  processes,  unlike  the  system  entity  diagram  which  included 
titles  of  the  functions,  denotes  action,  i.e.  ,  "Engage  Target". 
The  data  flow  diagrams  initially  were  developed  only  for 
the  four  functional  entities  of  command  and  control,  target 
control,  remote  communication  and  radar  interfaces.  Later 
the  top-level  flow  was  provided  separately  from  the  command 
and  control  which  initially  provided  the  relationship  be¬ 
tween  the  entities. 

The  data  flow  diagrams  begin  with  a  top  level  (context)  data 
flow  diagram  (Figure  2-11)  which  shows  the  data  flows  for  the 
overall  system.  The  second  level  data  flow  (Figure  2-12) 
shows  the  top  level  diagram  for  the  battalion  system 
which  is  subsequently  decomposed  into  detailed  flow  to  the 
lower  entities.  The  data  flow  diagrams  are  included  as 
Appendix  E. 

The  major  shortcomings  of  the  data  flow  diagrams  are  that 
they  do  not  provide  control  information  or  the  direction 
of  the  data  flow.  The  direction  of  flow  is  reflected  later 
in  the  structure  chart  where  control  is  also  illustrated. 

In  developing  the  detailed  flows  for  target  control,  the 
programmer  analyst  had  a  tendency  to  look  for  data  control 
that  is  normally  associated  with  the  traditional  method  of 
flow  charting.  Secondly,  the  data  flows  do  not  show 
parallelism  or  sequence  of  events  that  are  traditionally 
found  in  data  flow  charting.  Once  the  traditional  views 
were  overcome,  the  development  of  data  flows  was  relatively 
easy. 

The  data  flow  diagrams  were  based  upon  the  AN/TSQ-73  docu¬ 
mentation  provided  by  the  USA  CECOM.  In  the  development 
of  a  new  system,  the  data  fT.ow  diagram  would  be  produced 
in  close  coordination  with  the  user  and  ould  be  based  upon 
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Figure  2-12-  Second  Level  Flow  Diagram 


DATA  FLOW  DIAGRAMS  (continued) 

a  thorough  analysis  of  the  requirements.  The  provided  speci¬ 
fication  defined  the  requirements  to  a  level  of  detail  that 
permitted  development  of  the  data  flow  diagrams.  The  input, 
output  and  storage  were  more  readily  identifiable  from  the 
AN/TSQ-73  specifications.  The  identification  of  the  pro¬ 
cesses  was  more  difficult  in  that  the  descriptions  were  not 
apparent  or  were  not  provided  in  the  specifications.  An 
exception  is  the  algorithms  for  the  tracking  functions.  As 
a  result,  the  program  analyst  relied  heavily  upon  data  flows 
and  his  own  analysis  of  the  requirements.  The  analyst  also 
and  a  learning  process  in  some  area  such  as  radar  operations 
and  interfaces.  To  avoid  loss  of  productive  time,  the 
analyst  used  his  own  initiative  to  increase  his  knowledge 
in  areas  of  need.  In  addition,  Control  Data  provided  a 
consultant  in  air  defense  operation. 

The  four  packages,  command  and  control,  target  control, 
radar  communications,  and  remote  communications,  were  developed 
by  separate  analysts;  therefore,  there  were  some  duplica¬ 
tions  in  the  flows.  This  resulted  in  some  changes  in  the 
SEDs,  SDL  and  the  data  flows.  A  more  detailed  walkthrough 
of  the  design  earlier  would  have  prevented  the  duplication. 
Nevertheless,  the  duplication  was  identified  and  eleminated 
early. 

The  remote  communications  package  was  selected  as  the 
package  to  validate  the  methodology;  therefore,  a  more 
thorough  analysis  was  accomplished  in  this  area.  The  pack¬ 
age  with  the  most  detail  is  target  control  since  the  subfunc¬ 
tion  to  be  designed  and  programmed  is  a  part  of  this 
function . 
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DATA  FLOW  DIAGRAMS  (continued) 


The  preparation  of  the  data  flow  diagram  was  assisted 
by  use  of  computer  aided  design  tools  still  under 
development.  Automated  tools  show  a  significant  ad¬ 
vantage  in  that  they  can  identify  all  other  changes 
resulting  from  a  single  change  in  flow  diagrams  and 
provided  updates  with  relative  ease. 


2 . 5 . 3 . 2  DATA  DICTIONARY 


t 


The  data  dictionary  is  one  of  the  most  important  tools 
in  the  design  methodology.  The  data  dictionary  defines 
all  data,  data  flows,  transformations,  data  files, 
storage  areas,  reports,  etc.,  provided  in  the  data  flow 
diagrams.  In  normal  practice,  the  data  dictionary  would 
be  developed  as  a  result  of  a  thorough  analysis  in  con¬ 
junction  with  the  user. 


The  structure  of  the  process  descriptions  in  the  data 
dictionary  is  based  upon  Ada-like  pseudo  code.  To  arrive 
at  this  structure,  segments  of  the  target  control  were 
developed  using  both  Ada- like  pseudo  code  and  pure  Ada 
constructs  based  upon  MIL- STD-1 815 .  In  addition,  unam¬ 
biguous  definitions  of  data  flows  (vectors)  and  storage 
areas  (files)  are  provided  in  the  data  dictionary. 


2.5. 3. 3  STRUCTURE  CHARTS 

The  structure  chart  was  based  upon  a  concept  by  Steven 
C.  Myers  and  Larry  Constantine,  entitled  "Structured 
Design",  IBM  System  Journal,  1974,  (Reference  Appendix  A). 
The  structure  chart  utilized  the  information  from  the  data 
flow  diagrams  and  the  data  dictionary.  In  addition,  the 
structure  charts  separate  data  and  control  communications 
and  shows  the  direction  of  flows  for  each.  The  structure 
chart  may  also  show  loops  in  the  system.  The  reviewer 
of  the  design  can  use  the  charts  as  a  focus  of  the  design 
evaluation  process  as  long  as  all  program  and  modules  names, 
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STRUCTURE  CHARTS  (continued) 

functions  and  interfaces  are  defined  rigorously  in  the 
data  dictionary.  The  structure  chart  can  be  viewed  as 
follows : 

a.  A  top-level  hierarchical  software  design  for  use 
by  major  decision  makers  who  do  not  want  to  be 
involved  in  the  intricate  details  of  the  design. 

b.  A  hierarchical  design  of  lower  program  units  for 
analysts  and  programmers  who  are  concerned  with 
the  minute  details  of  the  software  design. 

In  order  to  create  a  structure  chart  from  a  data  flow 
diagram,  the  strategy  of  transform  analysis  was  employed 
Transform  analysis  locates  the  "central  transform"  by 
tracing  the  data  from  physical  input  for  logical  input 
and  from  logical  output  to  physical  output.  The  bubble 
or  bubbles  where  the  data  is  most  abstracted  from  the 
physical  become  the  central  transform  or  transforms. 

On  the  structure  chart  these  bubbles  would  become  boxes 
on  the  second  level.  A  controller  box  is  placed  above. 
Lower  level  boxes  represent  the  processing  of  the  data 
from  physical  inputs  to  physical  outputs.  By  utilizing 
transform  analysis,  the  role  of  intuition  in  building 
a  structure  chart  is  greatly  reduced.  The  advantages  of 
the  structure  chart  are  that  the  system: 

a.  Is  easier  to  develop  and  maintain  because  it 
reflects  the  software  design  in  a  highly  struc¬ 
tured  and  detailed  format. 

b.  Provides  systematic,  teachable  approach  for  trans¬ 
fer  of  information  and  training  to  the  analysis. 


STRUCTURE  CHART  (continued) 

c.  Intuition  is  avoided. 

Major  disadvantages  are  that  it  does  not  reveal  concurrent 
tasks  and  does  not  reflect  the  entities  to  the  lowest  level 
of  an  Ada  package,  procedure,  function  or  task  when  using 
Ada  HOL. 

PROGRAMMING  DESIGN  PHASE 

The  programming  design  phase  consisted  of  three  subphases: 
(1)  selection  of  program  unit  (module)  to  code,  (2)  pro¬ 
gram  design,  and  (3)  coding.  The  two  concepts  upon  which 
the  design  is  based  is  structured  design  and  the  applica¬ 
tion  of  the  complexity  measure  described  in  the  Ada  System 
Designer's  Guide,  Appendix  B. 

SELECTION  OF  PROGRAM  UNIT  FOR  PROGRAM  DESIGN  AND  CODING 

The  selected  subfunctions  for  coding  were  "Smoothing"  and 
"Prediction",  part  of  the  Target  Control  package  (Appendix 
D,  Ada- Based  System  Design  Language) .  These  subfunctions 
were  selected  for  the  following  reasons: 

a.  The  subfunctions  are  virtually  independent  of  the  other 
system  functions. 

b.  Each  subfunction  is  further  divisable  into  discrete 
program  units  for  coding  by  individuals. 

c.  Each  subfunction  is  easily  expandable  by  inclusion  of 
the  "front-end"  since  both  require  the  same  support 
software . 

d.  Both  subfunctions  require  non-trival  mathematical 
manipulation. 

e.  Both  subfunctions  can  be  tested  independent  of  the 
remainder  of  the  system. 
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f.  Both  subfunctions  enable  the  use  of  Ada's  unique  features. 

g.  The  subfunction  represents  functions  typical  of  an  air 
defense  system  with  real-time  constraints. 

The  program  units  for  these  subfunctions  are  identified  as 
"procedure  SMOOTHING"  and  procedure  PREDICTION"  (Appendix 
H  -  Ada-Based  Program  Design  Language) . 

The  tracking  function  (Figure  2-13)  consists  of  two  sequential 
actions,  the  "front-end"  which  processes  data  received  from 
the  radar  interface  equipment  and  outputs  associated  track 
pairing  to  the  "back-end",  smoothing  and  prediction.  The 
"back-end"  transforms  these  pairings  into  a  collection  of  - 

data  about  a  specific  target.  This  collection  of  data  in¬ 
cludes  the  targets  predicted  position  at  the  next  radar 
sweep  and  the  targets  current  corrected  (smoothed)  position, 
velocity  and  altitude.  In  order  to  complete  the  smoothing  process,-' 
maneuver  detection  analysis  must  also  be  performed.  This  infor¬ 
mation  is  then  used  by  the  system  to  update  the  master  file 
of  current  track  information  (track  storage  file).  Since 
these  update  functions  are  actually  the  responsibility  of 
the  subfunction  of  track  manager  (2.3)  or  more  specifically 
manage  tables  (2.3.2)  (Appendix  C  -  System  Entity  Diagram), 
those  procedures  necessary  to  perform  the  update  were  also 
included  in  the  coding  effort. 

The  Ada  package  that  contains  the  procedures  for  smoothing 
and  prediction  consists  of  two  major  areas:  (1)  the  smoothing 
algorithms,  files  and  the  code  to  manipulate  them,  and  (2) 
the  support  routines. 

a.  Algorithms  -  the  smoothing  algorithms  are  implemented 
as  Ada  procedures  or  functions  which  are  called  by  the 
control  logic  of  the  smoothing  package. 

b.  Files  -  the  major  file  involved  is  the  track  storage 
file.  This  file  would  be  seen  by  the  system  as  a 
package  which  offered  file  access  procedures  (e.g., 
get,  put)  and  functions  (e.g.,  find).  The  package 
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Figure  2-13  -  Tracking  Function 
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2.5. 4.1  SELECTION  OF  PROGRAM  UNIT  FOR  PROGRAM  DESIGN  AND  CODE (continued) 


itself  contains  a  task  that  manages  the  actual  physical 
representation  of  the  file  and  at  the  same  time  allows 
queuing  of  access  requests. 

c.  Code  -  the  code  that  manipulates  the  files  consists  of 
user-defined  data  typ-.-s,  exception,  and  exception  hand¬ 
lers  and  numerical  algorithms  necessary  to  transform 
the  radar  report  into  its  finished  form. 

d.  Support  Routines  -  the  support  routines  are  comprised 
of:  (1)  a  vector  and  arithmetic  package  containing  over¬ 
loaded  definitions  of  standard  scalar  operations  that 
will  allow  vector  operations,  and  (2)  trigonometric 
functions . 

2.5. 4.2  PROGRAM  DESIGN 

The  design  of  the  program  units  selected  for  coding  is  based 
upon  the  data  flow  diagrams,  data  dictionary  and  the  struc¬ 
ture  charts.  The  program  unit  design  consists  of  two  parts  - 
specification  and  the  body  defined  in  MIL-STD-1815 .  The 
following  constructs  were  identified  in  Appendix  B,  System 
Designer's  Guide,  Design  Plan,  and  below  for  use  as  a  PDL: 

•  Accept 

•  Begin... End 

•  Case  Is... End  Case 

•  Do. . .End 

•  Entry 

•  Exception 

•  Exit 

•  Function 

•  For  Loop . . . End  Loop 

•  If  Then. .. Else ...  (ELSIF) ...  End  If 

•  Is 

•  Loop... End  Loop 

•  Package 

•  Raise 

•  Record 
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•  Return 

•  Select... End  Select 

•  Task 

•  Type 

•  Use 

•  When 

•  While 

•  With 

Although  originally  the  use  of  an  Ada  subset  seemed  attractive 
for  a  PDL  definition,  this  approach  eventually  proved  to  be 
restrictive.  Therefore,  when  the  program  design  was  completed, 
it  was  accomplished  using  the  full  Ada  language  as  defined  in 
MIL-STD-1815  as  the  PDL.  The  use  of  PDLs  was  probably  one  of 
the  first  design  tools  that  was  created  for  software  develop¬ 
ment.  Even  before  the  use  of  flow  charts  became  widespread, 
programmers  found  that  an  English-like  description  of  what  was 
to  be  coded  often  identified  potential  problems  prior  to 
coding.  This  description  process  evolved  to  the  program  de¬ 
sign  language  as  known  today,  which  is  commonly  referred  to 
as  the  tool  and  phrase  by  the  same  name. 

The  PDL  tool  that  is  most  widely  used  today  is  pseudo  code. 

A  pseudo  code  is  a  non-executable  programming  language  that 
allows  a  designer/programmer  to  "write"  sections  of  the  pro¬ 
gram  without  being  concerned  with  the  details  of  the  intended 
implementation  language.  The  PDL  description  is  intended 
to  embody  much  of  the  control  structure  and  algor ithmetic 
content  of  the  program  so  that  these  components  can  be  verified 
as  correct  without  the  added  complication  of  logically  checking 
lower  level  details  that  do  not  impact  upon  this  higher,  logi¬ 
cal  level.  Pseudo  code  enforces  this  separation  of  logic  and 
detail  by  providing  little  or  no  capability  for  expressing 
detail.  The  use  of  pseudo  code  also  enforces  a  structured 
phase  design  approach  because,  regardless  of  the  completion 
of  the  PDL  description,  a  final  PDL-to-code  phase  is  always 
required. 
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In  approaching  the  problem  of  creating  an  Ada  PDL,  the 
problem  was  stated  simply  as;  "In  what  areas  of  an  Ada 
program  design  is  the  traditional  pseduo  code  definitive?" 
Investigation  of  this  question  quickly  revealed  two  things 
(1)  traditional  pseudo  code  could  be  used  for  "low  level" 

Ada  constructs  such  as  simple  functions  and  procedures, 
but  was  inadequate  for  describing  tasks,  generic  packages, 
etc.,  and  (2)  our  original  estimation  of  the  problem  was 
grossly  understated.  Our  second  iteration  was  based  on 
the  premise  that  a  pseudo  code  could  be  developed  suitable 
for  Ada  design.  The  natural  choice  was  Ada  itself,  based 
upon  some  subset  of  Ada  that  could  describe  these  areas 
not  described  by  traditional  Ada  code.  The  pseudo  code 
would  not  be  exact  Ada  "code";  therefore,  separate  dis¬ 
tinct  phases  would  be  maintained.  The  approach  had  merit 
and  was  investigated  further.  When  the  Ada  subset  was 
completed  and  subsequently  revised,  the  subset  invariably 
resulted  in  the  omission  of  some  Ada  feature  that  was 
expressly  designed  to  describe  a  specific  issue.  Using  the 
subset  resulted  in  a  poor  and  overly  complicated  description 
of  features  that  were  elegantly  described  by  the  omitted 
Ada  features.  Finally,  our  decision  was  to  use  the  full 
Ada  language  as  the  PDL,  but  with  reluctance.  The  use  of 
the  full  Ada  language  offers  a  potentially  more  serious  problem; 
there  was  no  distinction  or  step  between  PDL  and  code. 

Every  line  of  PDL  was  potentially  a  part  of  the  program 
which  the  PDL  was  intended  to  describe;  therefore,  PDL 
could  be  viewed  as  coding. 

Our  decision  implied  the  following: 

Ada's  power  of  abstraction  is  sufficiently  greater 
to  allow  the  elimination  of  one  of  the  abstraction 
tools  used  in  the  traditional. design  methodology,  or  an 
artificial  "breakpoint"  must  be  introduced  to  sep¬ 
arate  design  and  coding. 

Both  were  partially  true.  The  use  of  the  full  Ada  language 
eliminated  the  final  design  step,  but  in  name  only.  Since 
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the  traditional  coding,  i.e.,  writing  executable  code  now 
began  at  the  PDL  step,  the  PDL-to-code  transition  ceased 
to  exist.  However,  the  only  program  units  completely 
coded,  i.e.,  executable,  were  those  at  the  highest  logi¬ 
cal  levels  in  the  structure  charts.  The  remainder  of  the 
program  design  was  coded  only  as  specification  sections, 
with  studies  or  just  comments  indicating  how  the  design 
should  be  implemented  or  coded.  This  separation  of  those 
program  units  "at  the  top"  from  those  'lower  level"  program 
units  constituted  an  artificial  breakpoint.  The  levels  of 
design  which  were  retained  through  the  separation  are  no 
longer  obvious  or  easily  defined.  In  the  AN/TSQ-73  design, 
the  specification  and  body  identified,  as  a  minimum,  the 
structure  chart  program  units  in  terms  of  execution  type 
(packages,  procedures,  tasks  and  functions).  In  addition, 
the  program  design  expanded  upon  the  structure  charts  in 
areas  where  the  structure  charts  could  not  capture  all  the 
functionality  due  to  constraints  in  the  Ada  design  language. 

The  program  design  phase  used  two  techniques  during  the  pro¬ 
gram  design  and  coding  phase  which  were  McCabe's  Complexity 
Measure  and  Structured  Programming  Techniques.  Both  tech¬ 
niques  are  defined  in  the  Ada  System  Designer’s  Guide, 

Appendix  B. 

McCabe's  measure  was  designed  to  constrain  excessive  branching 
within  any  given  module.  Decision  statements  (IF_THEN_ELSE , 
DO_WHILE,  CASE)  increase  logical  complexity  and,  therefore, 
must  be  kept  within  a  numeric  bound.  This  measurement  was 
found  useful  for  Ada  procedures  and  functions,  but  will  need 
to  be  enhanced  for  Ada  tasks,  packages,  and  strong  typing 
capability. 
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2. 5. 4. 2  PROGRAM  DESIGN  (continued) 


The  second  technique  was  structured  programming  which 
utilized  three  control  structure  forms  commonly  referred 
to  as  sequence,  conditional,  and  looping.  Hierarchical 
indentif ication  on  the  computer  print-out  listing  also 
aided  human  readability  and  comprehension. 

2. 5. 4. 3  CODING 

Basically,  the  coding  phase  is  the  completion  of  the 
body  in  the  program  design.  The  coding  was  accomplished 
by  using  the  VAX/PDP  11/780  located  at  Fort  Monmouth, 

New  Jersey  using  a  remote  VT-100  terminal.  The  use  of 
an  off-site  terminal  and  the  Ada/Ed  Translator  was  slow 
and  time-consuming  to  the  programmer.  In  addition,  the 
translator  had  very  poor  runtime  debugging  facilities 
which  added  a  degree  of  difficulty  to  the  debugging 
effort.  Although  the  use  of  the  translator  caused  a 
large  degree  of  frustration  to  the  programmer,  it  served 
as  an  excellent  learning  tool. 

The  coding  of  the  selected  program  units  in  Ada  provided 
the  best  learning  tool  for  gaining  an  in-depth  knowledge 
of  the  Ada  language.  The  programmers  estimated  that 
eighty  (80)  percent  of  the  Ada  language  knowledge  was 
gained  during  this  phase  of  the  development.  The 
programmers  concluded  that  Ada  is  not  easy  to  use,  but 
makes  problem  solving  much  easier. 


The  Ada  language  offers  a  large  number  of  options  for 
solving  any  given  problem.  The  variety  of  options  produce 
a  situation  in  which  the  best  method  to  use  Ada  is  diffi¬ 
cult  to  determine.  A  good  example  of  this  problem  is 
illustrated  in  our  choice  of  a  method  to  process  radar 
data.  Control  Data  used  a  collection  of  tasks  with  a 
controller  for  the  task  management,  but  Control  Data  and 
Softech  identified  several  other  methods  that  were  equally 
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2. 5. 4. 3  CODING  (continued) 


viable.  Experience  and  hardware  limitations  will  probably 
determine  the  method  for  using  Ada  in  the  future. 

The  programmers  found  that  Ada  is  a  very  powerful  language. 
The  language  allows  the  implementation  of  complexed 
ideas  while  still  thinking  of  the  ideas  in  terms  of  abstrac¬ 
tion.  The  result  is  that  Ada  tends  to  expand  the  traditional 
limits  of  programming  language  which  was  the  main  motivation 
for  the  PDL.  The  PDL  worked  because  Ada  provided  both  the 
power  and  abstraction  capability  needed  at  the  PDL  stage. 

The  most  significant  problem  that  was  encountered  during 
coding  was  the  use  of  Ada's  concept  of  scope.  Scope  is 
an  encapsulation  technique  that  promotes  low  coupling. 

For  example,  an  object  declared  in  a  procedure  cannot  be 
accessed  outside  of  the  procedure.  This  limits  the  use 
of  scope  to  the  procedure  in  which  it  was  declared.  Ob¬ 
viously,  this  limitation  prohibited  the  object  from  being 
accessed  and  changed  from  outside  of  the  procedure.  This 
limitation  also  applies  to  Ada  program  units,  types  and 
blocks.  Since  programmers  were  not  used  to  the  use  of 
scope,  they  tended  to  violate  the  rules  for  its  usage. 

Ada  does  not  force  the  programmer  to  write  understandable 
code.  Therefore,  design  has  a  profound  effect  on  the 
ensuing  code.  The  lack  of  a  good  design  can  result  in 
poor  code  even  when  written  in  Ada.  Our  initial  experiences 
indicate  that  the  software  design  must  consider  the  use  of 
the  Ada  language  early  in  the  design  phase. 
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VERIFICATION  AND  TEST 


TEST  SCENARIO 

The  Ada  code  was  tested  by  providing  a  table  of  simulated 
"front-end"  output  to  drive  the  "back-end".  The  output  of 
the  "back-end"  will  be  before  and  after  "snapshots"  of  the 
system  tables,  especially  the  track  storage  files,  showing 
the  changes  in  the  files  produced  by  a  specific  input. 

By  observing  the  changing  track  position  values  in  the 
track  storage  file,  a  simulated  view  of  the  targets  move¬ 
ments  will  be  observed.  Since  the  display  update  portion 
of  the  system  uses  the  track  storage  coordinates  to  assemble 
the  synthesized  video  portion  of  the  display,  this  file 
contains  the  same  information  as  required  by  the  display. 
Testing  will  occur  at  two  levels.  Individual  program  units 
will  be  tested  after  separate  compilation  and  the  integrated 
separate  parts  will  be  tested  as  a  unit. 

PROGRAM  FILES 

The  support  package  for  the  smoothing  and  prediction  include 
files,  the  code  to  manipulate  files  and  algorithms  and  the 
support  routines.  The  files  and  support  routines  include: 

•  Track  sto  age  files,  and  radar  reports. 

•  Exception  handlers  and  the  numeric  algorithms  to  trans¬ 
form  radar  reports  in  finished  form. 

•  Any  special  software  to  execute  the  program. 

TEST  EXECUTION 

The  test  is  a  single  thread  test  as  described  in  the  test 
scenario  above. 


2. 5.5.4  TEST  RESULTS 


The  program  unit  tests,  Appendix  I,  were  successfully 
completed  on  18  June  1982.  The  integration  tests  will 
be  completed  30  June  1982. 

2.6  DOCUMENTATION 

This  section  briefly  describes  the  documentation  delivered 
as  a  part  of  this  contract. 

2.6.1  WORK  PLAN 

The  work  plan  was  completed  and  delivered  to  the  Government 
on  August  14,  1981.  The  work  plan  was  described  previously 
in  Paragraph  2.1. 

2.6.2  ADA  DESIGNER'S  GUIDE 

The  Ada  Designer's  Guide  (Appendix  B)  defined  the  procedures 
to  be  used  in  the  development  of  the  software  design  meth¬ 
odology.  The  designer's  guide  included: 

a.  Statement  of  the  problem. 

b.  Methodology  rat 5  onale  and  overview. 

c.  Description  of  the  system  entity  diagram  and  system 
design  language. 

d.  Description  of  data  flow  diagrams. 

e.  Data  dictionary. 

f.  Structure  charts. 

g.  Program  design  language. 

h.  Complexity  measure. 

i.  Structured  programming. 

j.  Design  reviews. 

k.  Program  design  methodologies. 
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2.6.2  ADA  DESIGNER'S  GUIDE  (continued) 

The  Ada  Designer's  Guide  was  not  a  deliverable  under  the 
contract,  but  copies  were  provided  to  the  Government  and 
Adjunct  Contractor.  The  Ada  Designer's  Guide  is  also 
provided  as  Appendix  B  of  this  report. 

2.6.3  DESIGN  PLAN 

The  design  plan  described  the  research  and  development 
effort  for  a  twelve-month  period  to  provide  a  top-level 
design  and  documentation  of  a  large  scale  software  system. 

The  design  plan  included  the  following: 

a.  Summary. 

b.  Design  methodology. 

c.  Design  methodology  validation. 

d.  Application  of  the  design  methodology  to  the  AN/TSQ-73 
Missile  Minder  System. 

e.  Technical  skills  acquisition. 

f.  Data  collection  and  recording. 

g.  Schedules. 

h.  Description  of  Control  Data's  automated  tools  * 

i.  Software  support  center. 

j.  Ada  PDL  -  reserved  words  and  syntax  diagrams. 

The  design  plan  was  prepared  late  in  the  contract,  therefore, 
the  design  plan  reflected  the  latest  results  of  the  "lessons 
learned"  throughout  the  early  days  of  the  contract.  To  date, 
deviations  from  the  plan  have  been  minimized.  Any  deviations 
appear  in  the  depth  of  the  design  required  by  the  design  plan 


The  draft  design  plan  was  delivered  February  25,  1982,  an  i 
later  revised  to  include  additional  information. 
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2.6.4 


VALIDATION  REPORT 


The  validation  report  validates  the  proposed  design  meth¬ 
odology  that  was  created  by  Control  Data's  Shrewsbury 
Facility  in  conjunction  with  the  redesign  of  the  Missile 
Minder  AN/TSQ-73  System.  The  results  of  the  validation 
were  provided  to  the  Government  as  a  courtesy  copy  and 
is  further  detailed  in  Paragraph  2.4. 

2.6.5  FINAL  REPORT 

This  report  documents  the  results  of  the  entire  contract 
period  and  includes  the  products  developed  as  a  part  of 
this  contract. 

2.7  TECHNICAL  INTERCHANGE  MEETINGS 

The  technical  interchange  meetings  were  informal  meetings 
between  the  Ada  support  contractor  and  the  Adjunct  Con¬ 
tractor  (Softech)  for  the  purpose  of  discussing  problems, 
issues,  the  use  of  the  Ada  language,  clarifying  areas  of 
MIL- STD- 1815,  status,  and  other  information.  The  meetings, 
chaired  by  the  Contracting  Officer's  Representative  were 
held  on  the  following  dates  and  locations: 

December  16,  17,  1981  -  Shrewsbury,  New  Jersey 

January  20,  21,  1982  -  Shrewsbury,  New  Jersey 

March  11,  12,  1982  -  Shrewsbury,  New  Jersey 

April  15,  16,  1982  -  Shrewsbury,  New  Jersey 

June  2,  3,  1982  -  Shrewsbury,  New  Jersey 
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TECHNICAL  FINDINGS 


This  section  of  the  document  reports  on  significant  techni¬ 
cal  findings  in  four  major  areas.  These  are: 

a.  Design  methodology  utility. 

b.  Ada  language  utility. 

c.  Project  team  factors. 

d.  Educational  considerations. 

3.1  DESIGN  METHODOLOGY  UTILITY 

The  basic  system  design  methodology  is  shown  in  Figure  3-1. 
This  Ada-based  design  methodology  is  viewed  as  three  dis¬ 
tinct  phases  encompassing  eight  separate  techniques: 

System  Entity  Diagram  (SED) 

System  Design  Language  (SDL) 

Data  Flow  Diagram  (DFD) 

Data  Dictionary  (DD) 

Structure  Charts  (SC) 

Program  Design  Language  (PDL) 

Complexity  Measure  (CM) 

Structured  Programming  (SP) 

As  the  contract  required  a  software  system  design  methodology, 
the  phases  after  system  design  were  oriented  toward  the 
software  design  of  the  system  with  the  hardware  design  more 
of  a  mental  picture  than  a  formalized  structure.  The 
following  sections  report  results  from  utilizing  the  system 
design  methodology  during  the  AN/TSQ-73  redesign. 

3.1.1  SYSTEM  DESIGN  PHASE 

The  system  design  phase  is  intended  to  accept  system  per¬ 
formance  requirements  (traditionally  known  as  system  or  "A" 
level  specifications)  as  input  and  provide  a  logical  method 


> 
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'j  System 
V  Design 
J  Phase 
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MANAGEMENT 


SYSTEM  DESIGN  PHASE  (continued) 


by  which  subsystem  ("B2"  &  "B5")  level  specifications 
may  be  produced  from  the  given  inputs. 

The  system  design  began  with  a  functional  requirement 
specification  in  which  functionality  was  treated  inde¬ 
pendently  of  ultimate  hardware  or  software  implementation. 

The  functional  requirements  and  subsequent  functional  de¬ 
composition  were  illustrated  in  graphical  form  by  system 
entity  diagrams  which  were  generated  for  the  uppermost 
levels  of  the  entire  redesign,  (see  Appendix  C) .  Each 
functional  "block"  was  hierarchically  numbered  in  order 
to  provide  accountability,  consistency,  and  traceability. 

The  numbering  scheme  employed  allowed  for  ease  of  modifi¬ 
cation  and  the  required  ripple-effect  tracing. 

The  system  entity  diagram  technique  proved  to  be  a  valuable 
communication  device  in  that  it  allowed  several  levels  of 
functionality  to  be  represented  in  a  single  illustration. 

The  system  entity  diagram  was  important  in  that  it  provided 
a  logical  grouping  or  an  overall  functional  grouping  that 
was  easily  understood  by  both  the  user  and  designer.  This 
technique  was  found  beneficial  for  system  changes.  For 
example,  upon  a  design  walkthrough,  the  entity  "OPERATOR 
SWITCH  ACTION"  component  under  command  and  control  was 
reassigned  as  an  entity  "Track  Manager"  component  under 
Target  Control.  The  impact  was  minimal  and  the  automated 
tool  generated  the  new  documentation.  The  SED  does  not 
specify  interface  description  between  functional  parts  of 
the  system.  The  interface  description  is  provided  by  the 
use  of  the  complimentary  SDL  technique  which  describes 
these  interfaces  by  Ada  constructs. 

It  was  originally  decided  to  limit  the  degree  of  decomposi¬ 
tion  by  the  System  Entity  Diagram  to  three  levels.  This  was 
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SYSTEM  DESIGN  PHASE  (continued) 


found  to  be  inappropriate  because  many  functional  areas 
appeared  to  require  further  definition  before  hardware  or 
software  tradeoff  decisions  could  be  made.  Therefore  a 
guideline  was  required  which  was  flexible  enough  to  allow 
for  varying  degrees  of  decomposition.  A  maximum  of  six 
levels  of  decomposition  was  found  to  provide  the  flexibility 
needed  for  the  redesign. 

Upon  completion  of  the  system  entity  diagrams  the  system 
design  language  (SDL)  technique  was  employed.  Various 
schemes  were  tested.  These  included: 

1.  Labelling  all  SED  blocks  as  procedures. 

2.  Proceeding  as  in  #1  but  including  comments 
appropriate  to  each  procedure. 

3.  Renaming  lower  level  procedures  to  indicate 
execution  type  (serial  or  concurrent) ,  packaging 
higher  level  program  unit  groupings  which  were 
logically  related,  including  the  numbering  se¬ 
quence  taken  from  the  corresponding  SED,  and  pro¬ 
viding  Ada-based  pseudo-code  descriptions  for 
each  procedure  or  task. 

As  a  result  of  the  experimentation  performed  with  the  SDL, 
sets  of  objectives,  characteristics  and  user  guidelines 
were'  defined. 

SDL  Objectives: 

The  SDL  must 

•  Be  suitable  for  human  understanding  (users, 
developers,  managers). 

•  Provide  system  input  for  hardware/software 
trade-off  evaluations  and  succeeding  design 
techniques . 

•  Provide  system  input  for  management  decisions. 

•  Provide  for  system  accountability. 
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SYSTEM  DESIGN  PHASE  (continued) 


•  Provide  for  system  consistency, 
e  Provide  for  ripple-effect  tracing, 
e  Provide  for  increased  productivity  through 
automation. 

e  Provide  a  primary  working  system  document. 

SDL  Characteristics: 

The  SDL  must  provide  for  specification  of: 
e  System  objectives. 

e  System  entities,  subentities,  and  their 
relationships . 
e  System  control . 
e  System  data  flow. 

e  System  requirements  and  capabilities, 
e  System  capacities . 
e  System  constraints . 
e  System  exception  handling. 

User  Guidelines: 

To  aid  in  the  use  of  the  SDL,  the  following  guidelines 
are  offered: 

e  Utilize  all  features  of  the  Ada  language 
necessary  to  provide  the  required  system 
descriptions,  while  maintaining  a  structured 
approach. 

e  Employ  the  Ada  program  units  according  to  the 
following  criteria: 

e  Utilize  packages  to  represent  collections 
logically  related  system  activities.  The 
items  identified  in  any  given  package  should 
be  logically  independent  from  those  repre¬ 
sented  in  other  packages, 
e  Utilize  procedures  and  functions  to  repre¬ 
sent  system  activities  which  appear  to  be 
sufficiently  distinct  to  act  as  stand-alone 
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SYSTEM  DESIGN  PHASE  (continued) 


units  to  accomplish  a  more  global  activity. 

•  Utilize  tasks  to  represent  activities  which 
can  provide  services  to  other  program  units 
in  a  concurrent  fashion. 

•  Proceed  to  a  level  of  detail  which  allows  hard¬ 
ware/software  trade-offs  to  be  made,  or  additional 
clarity  is  warranted. 

•  Provide  appropriate  comments  for  each  high  level 
program  unit. 


•  Maintain  consistency  with  numbering  conventions. 

•  Keep  in  mind  that  the  SDL  is  a  communicative 
device,  the  purpose  of  which  is  to  describe 
system  functionality. 

•  Do  not  attempt  to  write  executable  source  code. 


Development  of  the  SDL  based  on  the  information  provided 
by  the  completed  SED's  proved  to  be  difficult  for  several 
reasons.  The  completed  set  of  SED's  caused  a  degree  of 
confusion  for  .the  designer  because  the  lower  level  details 
had  already  been  revealed  before  the  SDL  was  begun.  Main¬ 
taining  the  thought  process  required  to  achieve  consistent 
high  levels  of  abstraction  was  hindered  by  the  revelation 
of  these  lower  level  details.  Therefore,  it  was  decided 
to  develop  the  SED  and  SDL  simultaneously,  with  one 
technique  proceeding  no  further  than  two  levels  ahead  of 
the  other  at  any  given  time. 

Although  the  SED's  were  complete  before  the  SDL  was  de¬ 
veloped,  the  conceptual  leap  required  to  move  from  the 
SED  to  the  SDL  proved  to  be  too  large  because  the  designer 
had  too  much  information  to  generate  for  each  functional 
"block"  or  entity.  The  execution  type,  the  interface,  the 
numbering  sequence,  a  functional  description,  and  Ada-like 
psuedo  code  had  to  be  generated  for  every  entity. 


C2t 
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SYSTEM  DESIGN  PHASE  (continued) 


The  system  design  phase  purpose  is  ultimately  to  provide 
input  to  the  hardware  and  software  design  phases.  In  order 
to  provide  a  smooth  transition  between  phases,  the  techniques 
comprising  each  phase  should  be  compatible  so  that  the 
transfer  of  information  does  not  result  in  any  deletions, 
additions,  or  modifications.  The  software  design  phase 
begins  by  utilizing  the  data  flow  diagram  and  data  dictionary 
techniques.  Use  of  the  SED-SDL  techniques  in  the  system 
design  phase  did  not  provide  a  strong  enough  link  to  the 
software  design  because  of  the  conceptual  differences 
between  both  the  graphical  and  textual  techniques  utilized 
in  the  different  phases. 

The  system  design  phase  thus  was  deficient  in  several  ways. 
The  major  problems  included: 

•  The  lack  of  interface  definitions  in  graphic  form. 

•  And  the  poor  link  between  the  system  and  software 
design  phases. 

To  alleviate  these  problems,  two  techniques  were  tried  at 
the  system  design  level,  the  system  data  flow  diagram 
and  the  accompanying  data  dictionary. 

The  system  data  flow  diagram  illustrates  system  functional 
units  (Bubbles) ,  functional  unit  interfaces  (Vectors)  and 
system  boundaries  (Rectangles) .  The  data  dictionary  entires 
for  these  items  are  maintained  as  they  would  be  for  a  soft¬ 
ware  data  dictionary. 

The  system  data  flow  diagram  and  data  dictionary  were  found 
to  illustrate  linkage  by  providing  for  the  graphical  iden¬ 
tification  of  functional  interfaces,  and  by  providing  func¬ 
tional  and  interface  descriptions  prior  to  PDL  generation. 


II-3-7 


package  REMOTE  COMMUNICATION  (3.0)  is 

—  The  objective  of  the  REMOTE  COMMUNICATION  SYSTEM 

—  (3.0)  is  to  enable  the  AN/TSQ-73  to  communicate 

— digitally  with  various  remote  sites  by  means  of  the 
— previously  defined  military  protocols,  TADIL-B, 

— ATDL-1,  and  modified  MBDL.  The  remote  communication 
— subsystem  shall  provide  for: 

-2  group  data  links  (ATDL-1) 

-2  battalion  data  links  (ATDL-1) 

-1  tactical  operations  system  data  link  (ATDL-1) 

-1  air  traffic  management  system  data  link  (ATDL-1) 
-1  inter-service  communication  data  link  (TADIL-B) 
-4  fire  unit  data  links  (MBDL) 
end  REMOTE  COMMUNICATION; 


Figure  3-2  -  Ada  SDL  Exhibits  System  Objectives 
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The  system  design  phase  purpose  is  ultimately  to  provide 
input  to  the  hardware  and  software  design  phases.  In  order 
to  provide  a  smooth  transition  between  phases,  the  techniques 
comprising  each  phase  should  be  compatible  so  that  the 
transfer  of  information  does  not  result  in  any  deletions, 
additions,  or  modifications.  The  software  design  phase 
begins  by  utilizing  the  data  flow  diagram  and  data  dictionary 
techniques.  Use  of  the  SED-SDL  techniques  in  the  system 
design  phase  did  not  provide  a  strong  enough  link  to  the 
software  design  because  of  the  conceptual  differences 
between  both  the  graphical  and  textual  techniques  utilized 
in  the  different  phases. 

The  system  design  phase  thus  was  deficient  in  several  ways. 
The  major  problems  included: 

•  The  lack  of  interface  definitions  in  graphic  form. 

•  And  the  poor  link  between  the  system  and  software 
design  phases. 

To  alleviate  these  problems,  two  techniques  were  tried  at 
the  system  design  level,  the  system  data  flow  diagram 
(Figure  3-2)  and  the  accompanying  data  dictionary. 

The  system  data  flow  diagram  illustrates  system  functional 
units  (Bubbles) ,  functional  unit  interfaces  (Vectors)  and 
system  boundaries  (Rectangles) .  The  data  dictionary  entires 
for  these  items  are  maintained  as  they  would  be  for  a  soft¬ 
ware  data  dictionary. 

The  system  data  flow  diagram  and  data  dictionary  were  found 
to  illustrate  linkage  by  providing  for  the  graphical  iden¬ 
tification  of  functional  interfaces,  and  by  providing  func¬ 
tional  and  interface  descriptions  prior  to  PDL  generation. 
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package  REMOTE  COMMUNICATION  (3.0)  is 

—  The  objective  of  the  REMOTE  COMMUNICATION  SYSTE’ 

— (3.0)  is  to  enable  the  AN/TSQ-73  to  communicate 
— digitally  with  various  remote  sites  by  means  of  t 
— previously  defined  military  protocols,  TADIL-B, 

— ATDL-1,  and  modified  MBDL.  The  remote  communicai  . 

— subsystem  shall  provide  for: 

-2  group  data  links  (ATDL-1) 

-2  battalion  data  links  (ATDL-1) 

-1  tactical  operations  system  data  link  (ATDL-1) 

-1  air  traffic  management  system  data  link  (ATDL-1) 
-1  inter-service  communication  data  link  (TADIL-B) 

—  -4  fire  unit  data  links  (MBDL) 
end  REMOTE  COMMUNICATION; 
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SYSTEM  DESIGN  PHASE  (continued) 


The  fact  that  the  system  data  flow  diagrams  and  the  data 
dictionary  can  be  continued  in  the  software  design  phase 
provides  a  strong  link  between  design  phases. 

The  drawback  to  this  configuration  is  that  the  system 
data  flow  diagrams  alone  do  not  represent  a  large  easily 
comprehendable  view  of  the  system  on  any  given  illustration 
and  they  may  be  too  complex  to  promote  communications  .  This 
is  alleviated  by  the  continued  use  of  the  SED  to  provide 
a  simple  overall  illustration. 

3.1.2  SOFTWARE  DESIGN  PHASE 


The  software  design  phase  followed  the  completion  of  high 
level  system  design.  The  distinct  steps  of  the  software 
design  phase  are: 

a.  Preparation  of  data  flow  diagrams. 

b.  Preparation  of  data  dictionary. 

c.  Preparation  of  structure  charts. 

The  utility  of  the  data  flow  diagrams,  also  known  as 

"bubble  charts" ,  in  the  design  is  that  they  defined  graph¬ 
ically  all  the  input/output  data,  stored  data,  and  the 
processes  for  a  software  entity.  This  technique  provided 
a  clear  and  concise  view  of  the  major  functions  and  the 
data  exchanged  between  functions.  The  DFD  is  not  intended 
to  capture  control  elements  or  establish  hierarchy  for 
program  units.  Project  members  with  a  background  of 
utilizing  flow  charts  as  a  software  design  tool  initially 
found  it  difficult  not  to  impose  control  on  data  flows. 

It  was  found  also  that  there  was  not  a  one-to-one  correspond¬ 
ence  necessitated  by  the  number  of  bubbles  on  the  data  flow 
and  the  Ada  program  units.  The  bubble  for  smoothing  (2.2.7- 
Appendix  E)  eventually  subdivided  into  four  bubbles.  The 
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SOFTWARE  DESIGN  PHASE  (continued) 

actual  code  produced  only  one  Ada  program  unit,  namely 
a  procedure  called  smoothing  which  incorporated  the  function 
ality  of  those  four  bubbles  into  it.  Creating  four  separate 
units  would  have  resulted  in  unnecessary  overhead  by  caus¬ 
ing  multiple  calls  to  access  the  data  base.  This  example 
points  out  that  the  DFD  is  useful  in  developing  a  conceptual 
view  of  smoothing  as  having  four  distinct  functions,  while 
the  implementation  results  in  just  one  Ada  program  unit. 

The  data  dictionary  defined  all  flows,  files,  and  trans¬ 
formations  described  by  the  data  flow  diagrams.  It  is 
utilized  as  a  central  repository  for  data  definitions  and 
process  descriptions.  It  provided: 

a.  A  glossary  of  terms. 

b.  Standard  terminology. 

c.  Definition  of  data  on  data  flow  diagrams. 

d.  Definition  of  transformations  on  data  flow  diagrams. 

e.  Cross-referencing. 

f.  A  bridge  to  program  design. 

g.  Input  error  list  generation. 

It  was  found  during  the  AN/TSQ-73  redesign  effort  that  the 
data  dictionary  can  be  started  at  the  system  design  phase 
and  continued  in  the  software  design  phase  and  programming 
phase.  Furthermore,  data  described  in  the  dictionary  can 
easily  become  Ada  types  or  objects  at  the  code  level. 

The  structure  charts  provided  a  hierarchical  structure  of 
modules,  partitioned  the  software,  provided  data  control, 
and  showed  the  direction  of  communication  between  modules. 
Definitions  of  data  were  provided  by  the  data  dictionary. 
Structure  charts  provide  the  programmer  with  clearly 
established  relationships  between  program  units,  directional 
flow  of  data  and  control  of  information. 
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3.1.2 


SOFTWARE  DESIGN  PHASE  (continued) 


The  structure  chart  was  designed  for  sequential  processing 
systems  and  the  representation  of  tasks  and  other  Ada  fea¬ 
tures  (generics,  packages,  etc.),  in  the  charts  is  a 
fruitful  area  for  further  investigations. 

3.1.3  PROGRAMMING  PHASE 


The  programming  phase  is  the  last  phase  in  the  developed 
methodology.  The  steps  of  the  programming  phase  are: 

a.  Prepare  program  design  language. 

b.  Utilize  complexity  measure. 

c .  Prepare  code . 

The  program  design  language  was  based  on  the  Ada  language 
constructs.  The  program  design  language  provides  precisely 
the  definition  of  each  interface;  relationships  of  pack¬ 
ages,  procedures,  tasks  and  functions;  package  and  subpro¬ 
gram  descriptions;  dependencies,  parameters,  dependencies 
on  other  packages,  target  and  host  dependencies,  if  any, 
etc.  The  largest  difficulty  encountered  was  the  tendency 
to  elevate  all  the  details  of  the  implementation  code  to 
the  PDL  level.  The  objective  of  the  PDL  to  capture  the 
essential  structure  of  the  software  was  met. 

The  complexity  measure  attempted  to  measure  the  logical 
weight  of  a  program  unit  to  assist  is  designing  manageable 
and  maintainable  software.  McCabe's  measure  is  concerned 
with  the  control  flow  complexity  of  individual  program 
units.  The  measurement  of  data  flow  and  concurrency  (TASKING) 
was  not  meant  to  be  addressed  by  this  technique.  The  strong 
typing  and  tasking  capability  features  of  Ada  are  candidates 
for  extending  the  metric  to  more  fully  represent  the  total 
complexity  of  a  program  unit. 
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PROGRAMMING  PHASE  (continued) 

The  final  technique  employed  was  structured  programming. 
This  technique  allowed  for  only  a  limited  number  (three) 
of  control  concepts  to  be  used  in  combination  when  gener¬ 
ating  software  units.  Structured  programming  eliminated 
GOTO  statements  and  unnecessary  branching. 

SYSTEM  DESIGN  METHODOLOGY  CONCLUSIONS 


The  system  design  methodology  developed  during  this  effort 
is  applicable  to  the  system  and  software  design  phases  for 
embedded  computers.  A  high  degree  of  confidence  has  devel¬ 
oped  that  the  contructs  from  the  Ada  language  can  be  used 
in  the  design  process.  Specifically,  Ada  can  serve  as  both 
a  system  design  language  and  a  program  design  language. 
Sections  3.2.1  and  3.2.2  provide  further  discussion  on  Ada 
as  a  design  language  as  well  as  examples  from  the  AN/TSQ-73 
redesign  effort. 

The  use  of  the  design  methodology  described  in  this  report 
offers  significant  advantages  which  include: 

•  SED/SDL  Technique  for  System  Design  Process  -  These 
design  tools  can  be  used  in  sequence  or  concurrently 
to  produce  a  high  level  system  specification. 

•  Automation  -  All  techniques  in  the  methodology  can  be 
automated.  For  this  contract,  the  automated  techniques 
were  the  system  entity  diagram,  system  design  language, 
data  flow  diagrams,  data  dictionary,  structure  charts, 
and  program  design  language.  Automation  allowed  faster 
production,  more  efficient  change,  cleaner  documenta¬ 
tion  and  a  framework  for  reliability  checking  and  product 
visibility. 

•  Traceability  -  The  methodology  provided  for  the  trace- 
ability  of  requirements  to  code.  This  traceability 
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SYSTEM  DESIGN  METHODOLOGY  CONCLUSIONS  (continued) 


assured  that  (1)  all  requirements  have  been  included 
in  the  design  and  (2)  that  the  code  (or  any  intermediate 
design  documents)  actually  fulfills  the  requirements. 

•  Structured  Design  Techniques  for  Software  Design  Process 
The  design  techniques  (DFD,  DD,  and  SC)  are  extremely 
compatible  for  producing  detailed  software  design. 

•  Ada-Based  Program  Design  Language  -  Using  Ada  as  the 
target  language  demanded  that  the  PDL  offer  the  module 
designer  ways  of  using  the  considerable  power  which 
Ada  offers  in  the  areas  of  abstraction.  An  Ada  derived 
PDL  used  Ada  syntax  to  describe  the  Ada  abstractions, 
but  still  allowed  the  PDL  to  maintain  a  level  of  abstrac¬ 
tion  above  Ada  code. 

In  addition,  a  number  of  areas  were  identified  to  enhance 

the  system  design  methodology.  These  include  the  following 

items  and  will  be  further  expanded  in  section  5.0. 

•  Further  refinement  of  the  requirements  for  an  Ada  program 
design  language  to  be  utilized  during  the  programming 
phase  of  large  scale  software  system  construction. 

•  Development  of  a  set  of  software  management  techniques 
to  act  as  production  control  mechanisms. 

e  Development  of  a  full  complement  of  automated  tools  to 
achieve  the  maximum  effective  use  of  the  system  design 
methodology. 

•  Expansion  of  the  system  design  methodology  to  include 
detail  steps  for  the  hardware  design  and  fabrication 
process. 

ADA  LANGUAGE  UTILITY 


The  Ada  programming  language  constructs  were  well  established 
in  the  reference  manual  issued  by  the  U.  S.  Department  of 
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ADA  LANGUAGE  UTILITY  (continued) 


Defense,  1980.  These  syntactical  statements  must  be  submitted 
in  a  rigorous  and  executable  manner  to  all  validated  compilers 
During  the  course  of  this  project,  a  serious  attempt  was  made 
to  utilize  the  Ada  constructs  at  two  levels  of  abstraction 
above  the  code  level.  The  Ada  constructs  were  used  as  both 
a  system  design  language  and  a  program  design  language. 

It  should  be  noted  that  the  originators  of  Ada  envisioned 
it  as  a  high  powered  programming  language  only.  However, 
the  unique  features  of  Ada  which  support  the  general  prin¬ 
ciples  of  information  hiding  and  abstraction  seem  to  invite 
design  language  experimentation. 

The  system  design  language  is  part  of  the  overall  system 
design  process  and  acts  as  the  initial  technique  before 
functions  are  allocated  to  hardware  or  software.  Two  stated 
goals  for  the  SDL  are  to  capture  relevant  information  to 
aid  the  hardware/software  evaluation  trade-offs  and  to 
serve  human  communication  between  user  and  developer.  The 
SDL  was  found  capable  for  capturing  system  objectives,  re¬ 
quirements,  control,  data  flow,  capacities,  and  constraints. 

The  program  design  language  is  used  during  the  software 
design  process.  The  data  flow  diagrams,  data  dictionary 
and  structure  charts  serve  as  input  to  the  PDL.  Modules 
and  their  interfaces  have  been  identified.  The  PDL  es¬ 
tablishes  the  detailed  structure  which  the  actual  Ada 
code  will  assume. 

The  following  sections  report  on  the  utility  of  the  Ada  lan¬ 
guage  in  the  multiple  roles  of  system  design  language,  pro¬ 
gram  design  language,  and  programming  language. 
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ADA  AS  A  SYSTEM  DESIGN  LANGUAGE  (SDL) 


The  AN/TSQ-73  redesign  utilizing  an  Ada-based  system  design 
language  witnessed  a  number  of  evolutionary  changes  in  the 
SDL  objectives,  content  and  recommended  user  guidelines. 

The  resulting  SDL  achieves  the  objectives: 

a.  Provide  for  human  understanding  (users,  developers, 
managers)  of  system  requirements. 

b.  Provide  system  information  for  hardware/software  trade¬ 
off  evaluations  and  succeeding  design. 

c.  Provide  system  information  for  management  decisions. 

d.  Provide  for  system  accountability. 

e.  Provide  for  system  consistency. 

f.  Provide  for  ripple-effect  tracing. 

g.  Provide  for  increased  productivity  through  automation. 

h.  Provide  a  primary  working  system  document. 

In  order  to  guarantee  accomplishing  these  objectives,  the 
SDL  provided  informational  content  for  the  specification  of: 

a.  System  objectives. 

b.  System  entities,  subentities  and  their  relationships. 

c.  System  control,  data  flow  and  exception  handling. 

d.  System  requirements,  capacities,  and  constraints. 

The  unique  features  of  the  Ada  programming  language  allowed 
these  desired  qualities  to  be  brought  to  the  system  level. 
This  point  is  significant  enough  to  warrant  a  detailed 
description.  The  following  examples  are  excerpted  from 
the  AN/TSQ-73  redesign  for  illustrative  purposes: 

a.  Ada's  Capability  to  Exhibit  System  Objectives 

System  objectives  can  be  made  visible  by  successfully 
deploying  the  Ada  construct  of  the  comment  along  with 
the  four  basic  programming  units  (package,  task  func¬ 
tion  and  procedure) .  This  point  is  illustrated  for 
package  Remote  Communications  in  Figure  3-2,  Page  II-3-8 


II-3-15 


ADA  AS  A  SYSTEM  DESIGN  LANGUAGE  (SDL)  (continued) 


b.  Ada's  Capability  to  Exhibit  System  Entities,  Subentities 
and  Their  Relationships 

Entities,  subentities,  and  their  respective  relationships 
can  be  clearly  expressed  due  to  Ada's  unique  nesting  of 
programming  unit  constructs.  Packages,  especially,  pro¬ 
vide  a  logical  mechanism  for  grouping  related  system 
activities  and  maintaining  a  high  degree  of  functional 
independence.  Figure  3-3  illustrates  the  functional 
decomposition  of  the  AN/TSQ-73  into  four  major  areas. 
Remote  Communications  is  further  partitioned  in  the 
following  illustrations. 

c.  Ada's  Capability  to  Exhibit  System  Control,  Data  Flow, 
and  Exception  Handling 

System  control,  system  data  flow,  and  system  exception 
handling  can  be  captured  by  the  Ada  control  structures 
such  as  IF-THEN-ELSE ,  CASE  and  EXCEPTION.  These  con¬ 
structs  are  found  in  the  program  unit's  body  and  may  be 
necessary  for  a  hardware/software  trade-off  decision. 
Figure  3-4  illustrates  the  use  of  Ada  constructs  for 
exhibiting  control,  data  flow,  and  exception  handling. 

d.  Ada's  Capability  to  Exhibit  System  Requirements,  Capa- 


cities  and  Constraints 
Requirements,  capacities,  and  constraints  can  be  captured 
by  Ada's  strong  typing  facility.  Figure  3-5  illustrates 
these  points. 

Overall,  the  Ada  programming  language  appears  capable  of 
serving  as  a  system  design  language. 

ADA  AS  A  PROGRAM  DESIGN  LANGUAGE  (PPL) 

Historically,  the  use  of  Program  Design  Language  has  been 
a  tool  in  the  software  design  area.  As  described  by  Caine 
and  Gordon  its  purpose  being  "for  the  production  of 
structured  designs  in  a  top  down  form. "  The  data  currently 
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procedure  TSQ-73  is 

package  COMMAND  AND  CONTROL  (1.0)  is 

end  COMMAND  AND  CONTROL; 
package  TARGET  CONTROL  (2.0)  is 

end  TARGET  CONTROL; 

package  REMOTE  COMMUNICATION  (3.0)  is 

package  COMMUNICATION  SUPERVISOR  (3.1)  is 


end; 


package  INTRASYSTEM  TRANSFERS  (3.2)  is 


end; 

package  COMMUNICATION  PROTOCOLS  (3.3)  is 


end; 

end  REMOTE  COMMUNICATION  (3.0); 
package  RADAR  COMMUNICATION  (4.0)  is 

end  RADAR  COMMUNICATION; 
end  TSQ-73; 


Figure  3-3  -  Ada  SDL  Exhibits  Entities,  Subentities, 
and  Their  Relationships 
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procedure  CONSUME  INTERNAL  MESSAGE  (3.1.1)  is 
begin 

if  Command  and  Control  Message  or  Communication 
Protocol  Message  *  then 
case  Message  Type  is 

when  Initialize  Remote  Communication  => 

Queue  Message  to  Initialize  Remote  Communication  (3.1.2); 
when  Manage  Data  Links  => 

Queue  Message  to  Manage  Data  Links  (3.1.3); 
when  Manage  Messages  => 

Queue  Message  to  Manage  Messages  (3.1.4); 
when  others  => 

set  error  code  for  invalid  message  type; 
queue  to  produce  Internal  Message  (3.1.7) 
end  case; 
else 

set  error  code  for  invalid  message  originator; 
queue  to  produce  Internal  Message  (3.1.7); 
end  if; 

end  CONSUME  INTERNAL  MESSAGE; 


Figure  3-4  -  Ada  SDL  Exhibits  System  Control, 
Data  Flow,  and  Exception  Handling 
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type  PROTOCOL  CHOICE  is  (TADIL-B,  ATDL-1,  MBDL) ; 

BAUD  RATE  CHOICE : constant  array  (PROTOCOL  CHOICE)  of 
integer  :  =  (1200,  1200,  600); 
type  ORIENTATION  CHOICE  is  (BIT  ORIENT,  CHAR  ORIENT) ; 
type  TRANSMISSION  CHOICE  is  (PT  TO  PT,  MULTI  DROP) ? 
type  SYNCH  CHOICE  is  (SYNCHRONOUS,  ASYNCHRONOUS); 
type  MODE  CHOICE  is  (PRIMARY,  REDUNDANT); 

type  PRI  MBDL  LINK  SPEC  is 
record 

PROTOCOL  :  PROTOCOL  CHOICE  :=  MBDL; 

BAUD  RATE  :  INTEGER  :=  BAUD  RATE  CHOICE  (PROTOCOL); 
ORIENTATION  :  ORIENTATION  CHOICE  :=  CHAR  ORIENT; 
TRANSMISSION  :  TRANSMISSION  CHOICE  :=pt  TO  PT; 
SYNCH  :  SYNCH  CHOICE  :=  SYNCHRONOUS; 

MODE  :  MODE  CHOICE  :=  PRIMARY; 
end  record; 

type  RED  MBDL  LINK  SPEC  is 
record 

PROTOCOL  :  PROTOCOL  CHOICE  ;=  MBDL; 

BAUD  RATE  :  INTEGER  :»  BAUD  RATE  CHOICE 
(PROTOCOL) ; 

ORIENTATION  :  ORIENTATION  CHOICE  :=  CHAR  ORIENT; 
TRANSMISSION  :  TRANSMISSION  CHOICE  :=  PT  TO  PT; 
SYNCH  ;  SYNCH  CHOICE  :=  SYNCHRONOUS; 

MODE  :  MODE  CHOICE  :=  REDUNDANT; 
end  record; 

PRIMARY  MBDL  LINK  :  PRI  MBDL  LINK  SPEC  range  1...4; 
REDUNDANT  MBDL  LINK  :  RED  MBDL  LINK  SPEC  range  1...4; 


Figure  3-5  -  Ada  SDL  Exhibits  System  Requirements 
Capacities  and  Constraints 
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ADA  AS  A  PROGRAM  DESIGN  LANGUAGE  (PPL)  (continued) 

available  concerning  increased  productivity,  decreased 
debugging  efforts,  and  superior  products  comes  from 
projects  using  a  PDL  within  that  scope.  The  PDL  used 
during  this  project  maintains  this  historical  perspective. 

An  underlying  assumption  of  the  development  of  Ada  as  a 
PDL  is  that  Ada  would  be  the  implementation  language.  This 
immediately  raised  the  issue  of  identifying  a  distinct 
separation  between  design  and  code.  Using  the  implementa¬ 
tion  language  as  the  design  language  makes  this  a  gray 
area. 

The  objective  of  the  PDL  used  during  this  project  was  to 
create  a  framework  for  the  code  by: 

•  Identifying  all  procedures. 

•  Identifying  all  functions. 

•  Identifying  all  tasks. 

•  Identifying  all  packages. 

•  Defining  the  parameters  of  the  functions  and  procedures. 

•  Defining  the  global  data. 

•  Defining  the  logic  of  the  control  blocks. 

The  following  guidelines  were  employed: 

a.  Program  units  will  be  designed  to  solve  a  particular 
problem  and  have  logic  which  is  easy  to  describe. 

b.  Simple  solutions,  designs  and  interfaces  will  be  utilized 

c.  Program  units  will  be  enclosed  by  identifiable  boundaries 

d.  Program  units  can  only  be  referenced  from  other  parts 
of  the  program  by  its  name. 

e.  It  is  desireable  for  program  units  to  have  only  a  single, 
common  entry  and  a  single  common  exit.  With  tasks  and 
task  types  this  may  not  be  possible. 
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ADA  AS  A  PROGRAM  DESIGN  LANGUAGE  (PPL)  (continued) 

f.  Program  units  will  be  designed  using  the  top-down  concept. 

g.  Logic  flow  will  begin  at  the  top  and  flow  to  one  bottom 
exit  point  except  for  "Exceptions". 

h.  Logically  related  program  units  will  be  identified  for 
possible  implementation  as  Ada  packages. 

i.  The  comment  mechanism  is  utilized  where  information  can 
be  best  transmitted  for  human  communication  purposes  by 
English  text. 

The  general  strategy  of  the  PDL  was  to  define  completely  the 
higher  level  control  blocks,  in  particular  the  task  SECTOR_ 
PROCESSING_CONTROLLER  and  the  task  type  TRACK_WHILE_SCAN  (Ap¬ 
pendix  H).  The  lower  level  functions  and  procedures  called  by 
these  tasks  were  identified  in  the  specification  sections  of 
packages  and  had  only  their  interfaces  defined.  This  establishes 
program  unit  identity  and  detailed  communication  interfaces 
to  other  program  units.  Additionally,  many  types  were  required 
for  these  interfaces,  and  were  defined  and  placed  in. 
packages.  By  taking  this  approach  the  implementation  of  lower 
level  details  were  left  until  coding  time.  Comments  were  used 
extensively  in  the  PDL  in  order  to  describe  how  these  details 
could  be  accomplished. 

A  major  issue  that  arose  during  the  development  of  the  PDL  was 
that  of  a  relaxed  syntax  format  versus  Ada's  exact  syntax 
requirements.  The  latter  was  selected  over  the  relaxed  syntax 
for  a  number  of  reasons.  Primarily,  the  PDL  was  intended  to  be 
a  subset  of  the  code  and  therefore  exact  syntactical  require¬ 
ment  had  to  be  met.  Furthermore  in  keeping  with  the  spirit  of 
a  research  project,  the  PDL  was  compiled  to  see  if  the  semantic 
errors  that  occured  would  be  helpful  to  the  design  creating 
process.  A  machine  processable  PDL  has  been  identified  as  a 
major  issue  and  the  only  processing  available,  that  of  the  NYU 
translator,  also  drove  the  requirement  of  exact  syntax.  Pro¬ 
cessing  the  PDL  in  this  manner  could  be  useful  in  identifying 
scope  and  visibility  errors,  locating  interface  inconsistencies 
and  identifying  function  and  procedure  requiring  definitions. 
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ADA  AS  A  PROGRAM  DESIGN  LANGUAGE  (PPL)  (continued) 

Using  this  strategy  as  a  step  prior  to  coding  made  the 
actual  coding  effort  relatively  simple.  All  inter¬ 
faces  were  defined  as  well  as  higher  level  control  logic 
leaving  only  the  logic  of  lower  level  details.  There 
was  a  tendency,  however,  during  the  writing  of  the  PDL 
to  slip  into  coding.  No  formal  rules  about  when  design 
would  stop  were  defined.  Without  defining  a  formal 
guideline,  the  largest  difficulty  experienced  was  the 
tendency  to  elevate  all  the  details  of  the  implementation 
problem  to  the  PDL  level  of  abstraction. 

Also,  special  care  had  to  be  taken  to  preserve  the  PDL 
on  separate  files  for  documentation  purposes.  Since 
the  PDL  was  a  subset  of  the  final  code,  some  code  was 
created  by  adding  to  the  PDL,  thus  gobbling  up  the  audit 
trail.  Also,  after  compilation  it  became  necessary  to 
locate  some  of  the  items  of  the  package  in  order  to  solve 
some  visibility  problems  and  it  was  helpful  to  create 
some  new  package  names  to  reflect  these  changes. 


In  conclusion,  the  program  design  language  should  first 
be  used  to  complete  the  specification  portion  for  each 
program  unit.  This  establishes  program  unit  identity 
and  detailed  communication  interfaces  to  other  program 
units.  These  specification  sections  can  then  be  compiled 
before  details  are  provided  in  the  program  unit  bodies. 
Both  the  specification  section  and  the  body  section  carry 
a  description  of  the  purpose  for  the  program  unit.  This 
information  is  usually  available  from  the  SDL  description. 
The  data  dictionary  provides  type  descriptions  of  data 
and  process  descriptions  for  each  bubble  in  the  data  flow 
diagram  and  structure  charts.  This  information  can  guide 
the  generation  of  Ada  code. 
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3.2.3 


ADA  AS  A  PROGRAMMING  LANGUAGE 


The  Ada  programming  language  incorporated,  by  technology 
transfer,  proven  constructs  from  a  variety  of  research 
efforts.  Special  emphasis  was  placed  on  constructs  which 
promote  human  readability,  and  program  reliability  and 
maintenance.  These  constructs  include  packages,  generics, 
separate  compilation  sections,  types,  and  tasks.  In  a 
larger  sense,  these  features  support  encapsulation, 
information  hiding,  data  abstraction,  and  parallel 
processing. 


During  the  AN/TSQ-73  redesign  effort,  especially  in  the 
functional  area  of  target  control  which  was  chosen  for 
coding,  the  Ada  constructs  proved  beneficial.  The  code 
produced  appears  to  be  easily  readable  and  understandable 
as  well  as  maintainable.  The  major  concepts  utilized  and 
which  will  be  explored  in  this  section  are  Packages,  Tasks, 
Task  Types,  Rendevous,  Overloading,  and  Strong  Typing. 

The  code  for  the  selected  subfunction  of  the  Missile 
Minder  System  can  be  found  in  Appendix  I.  The  format 
followed  below  presents  the  concept  definition  and  dis¬ 
plays  expamples  of  Ada  code  with  a  discussion  of  the 
merit  of  the  application  in  the  AN/TSQ-73  air  defense 
system. 


3.2. 3.1 


PACKAGES 


Package  -  a  program  unit  specifying  a  collection  of  related 
entities  such  as  constants,  variables,  types,  subprograms, 
and  tasks. 
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3.1 


PACKAGES  (continued) 


The  package  facility  provides  a  major  structuring  cap¬ 
ability  to  software  system  design.  In  addition,  it 
provides  a  mechanism  for  information  hiding  implemen¬ 
tation  details  from  other  program  units.  Other  program 
units  need  only  see  the  specification  section  and  not 
the  body  where  the  work  is  accomplished.  A  major  design 
issue  is  how  many  packages  are  available  and  how  to 
group  related  program  units  within  a  package.  Strong 
cohesiveness  of  package  components  will  strengthen 
comprehension  and  consequently  aid  maintenance. 


The  packages  utilized  during  the  coding  effort  were: 

a.  VECTOR_OPERATIONS  PACKAGE 

b.  TRACKING_OPERATIONS  PACKAGE 
C.  TRACKING_DATA  PACKAGE 

d.  TRACK_STORES  PACKAGE 

It  was  found  useful  to  maintain  strong  logical  cohesive¬ 
ness  among  the  components  of  the  package.  The  VECTOR_ 
OPERATIONS  package,  for  instance,  can  be  viewed  as  a 
mathematical  library  with  functions  related  to  applica¬ 
tions  area  (operations  on  two  dimensional  vectors) .  The 
TRACK_STORES  package  contains  the  track  storage  file  as 
well  as  the  access  to  the  track  storage  file.  In  addi¬ 
tion,  it  provides  the  memory  management  and  access  man¬ 
agement.  The  user,  therefore,  only  needs  to  know  that 
reading  and  writing  to  the  track  storage  file  can  be 
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3. 2. 3.1  PACKAGES  (continued) 

accomplished  by  using  this  package.  Thus,  the  details 
of  memory  locations  or  updating  mechanics  need  not  be 
the  user's  concern. 


Figure  3-6  illustrates  the  specification  or  interface 
portion  of  these  packages  visible  to  outside  program 
units  desiring  services  for  either  vector,  manipula¬ 
tion  (add,  subtract,  multiply)  or  file  management  of 
track  storage  data. 
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3. 2. 3. 2  TASKS,  RENDEVOUS,  TASK  TYPES 

Tasks  -  program  units  with  the  capability  to  operate  in 
parallel  with  other  program  units. 

Rendevous  -  the  mechanism  by  which  two  tasks,  one  issuing 
an  entry  call  and  the  other  accepting  the  call,  achieve 
proper  synchronization. 
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Task  Type  -  A  specification  that  permits  the  subsequent 
declaration  of  any  number  of  similar  tasks.  The  task 
specification  establishes  the  interface  between  tasks 
of  a  given  type  and  task  of  a  different  type. 

During  the  coding  effort,  a  number  of  tasks  were  imple¬ 
mented  to  serve  functionally  distinct  purposes.  Tasks 
proved  to  be  a  valuable  mechanism  for  more  than  just 
addressing  concurrency.  The  tasks  described  in  the 
coding  phase  include: 
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3. 2. 3. 2  TASKS,  RENDEVOUS,  TASK  TYPES  (continued) 

a.  RADAR_INTERFACE  EQUIPMENT  (RIE) 

b.  SECTOR_PROCES  SOR  CONTROLLER 
C.  TRACK_WHILE_SCAN 

d.  F I LE_MANAGER 

The  TRACK_WHILE_SCAN  is  a  task  type.  Figure  3-7  illustrates 
the  relationships  between  the  tasks  in  the  coding  effort. 

The  RADAR_INTERFACE  EQUIPMENT  task  simulates  the  Radar 
Communication  function  (4.0)  in  the  AN/TSQ-73.  It  acts 
as  a  master  clock  rendevousing  with  the  SECTOR_PROCESSOR_ 
CONTROLLER  task  on  a  periodic  basis.  During  each  rende- 
vous,  the  RIE  provides  one  sector  worth  of  data  which  a 
portion  of  one  sweep  of  the  actual  radar  hardware  would 
normally  produce.  The  SECTOR_PROCESSOR_CONTROLLER  task, 
in  turn,  has  a  rendevous  with  TRACK_WHILE_SCAN  tasks  in 
order  to  pass  sector  data,  and  stop  and  start  the  proper 
tasks.  TRACK_WH I LE_SC AN  is  a  task  type  in  order  to  gener¬ 
ate  one  task  for  each  of  the  twenty  18°  sectors  described 
by  the  radar  sweep.  Each  interaction  between  the  SECTOR_ 
PROCESSOR_CONTROLLER  task  and  the  TRACK_WHILE_SCAN  task  is 
started  and  passed  its  corresponding  sector  data.  The 
task  three  sectors  "ahead"  is  stopped  in  anticipation  of 
imminent  updating. 

Finally,  a  task  was  used  as  a  FILE_MANAGER  mechanism. 

Since  Ada  procedures  and  functions  are  re-entrant,  the 
possibility  exists  for  data  losing  its  integrity  by 
being  accessed  by  more  than  two  routines.  In  light  of 
the  twenty  TRACK_WHILE_SCAN  tasks,  the  need  for  an 
orderly  updating  process  of  common  records  was  a  require¬ 
ment. 
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TRACK  STORES  TASK 


Figure  3-7  Relationship  Between  Tasks  In  Coding  Effort 


3. 2. 3. 2  TASKS,  RENDEVOUS,  TASK  TYPES  (continued) 


The  select  statement  of  Ada  tasks  provides  a  guard  against 
this  unfortunate  occurrence  by  its  instrinsic  queueing 
scheme.  All  requests  are  automatically  queued.  The  pro¬ 
grammer  is  relieved  of  the  responsibility  for  designing 
and  implementing  a  scheduler. 

3. 2. 3. 3  OVERLOADING 


Overloading  -  the  property  of  literals,  identifiers,  and 
operators  that  can  have  several  alternative  meanings  within 
the  same  scope. 

Overloading  is  a  convenient  mechanism  for  hiding  implementa¬ 
tion  details  from  the  user.  During  the  coding  effort,  the 
familiar,  operators  for  addition  (+) ,  multiplication  (*) ,  and 
subtraction  (-)  were  overloaded  to  apply  to  vector  operations. 
The  user  will  find  within  the  package  VECTORjOPERATIONS 
specification  section  three  available  functions  to  manipulate 
vectors: 

FUNCTION  "+"  (A,  B: VECT)  RETURN  VECT; 

FUNCTION  "*"  (A: FLOAT; B: VECT)  RETURN  VECT; 

FUNCTION  (A, B: VECT)  RETURN  VECT; 

These  functions  free  the  programmer  from  the  implementation 
details  or  mechanics  which  underlie  sum,  product,  or  differ¬ 
ence.  The  programmer  need  only  utilize  these  functions  and 
provide  data  in  the  correct  format. 

3. 2. 3. 4  STRONG  TYPING 


Strong  Typing  -  all  variables  and  expressions  at  compile 
time  will  be  one  member  of  a  possible  set  of  well  determined 
types. 
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STRONG  TYPING  (continued) 


The  strong  typing  mechanism  employed  in  Ada  mandates  decla 
ration  by  type  for  all  objects.  This  maximizes  the  com¬ 
piler's  ability  to  detect  typing  mismatches  in  expression 
evaluation  and  parameter  passing.  The  advantage  of  the 
strong  typing  capability  is  to  define  the  nature  of  an 
identifier's  attributes  as  well  as  a  range  of  values  which 
an  identifier  might  possess. 

type  SECTOR  is  NEW  INTEGER  range  1..20; 

In  this  example,  the  identifier  SECTOR  must  be  an  integer 
from  one  to  twenty.  An  attempt  to  give  SECTOR  a  value  of 
twenty-one  will  result  in  an  error  notice  at  compile 
time. 

The  subtype  feature  of  Ada  was  utilized  to  increase  read¬ 
ability  and  comprehension.  The  subtype  does  not  introduce 
a  new  and  distinct  type,  but  allows  the  operations  and 
values  of  an  established  type  to  be  transferred.  Subtypes 
DEVIATION_VECT,  PREDICTED_POS ,  SMOOTH_POS,  and  SMOOTH_VEL  . 
were  used  ih  PACKAGE_TRACKING_OPERATIONS .  These  terms  are 
ordered  pairs  like  VECT. 

TYPE  VECT  IS 

RECORD 
X; FLOAT; 

Y; FLOAT; 

END  RECORD; 


SUBTYPE  DEVIATION_VECT  IS  VECT; 
SUBTYPE  PREDICTED_POS  IS  VECT; 
SUBTYPE  SMOOTH_POS  IS  VECT: 
SUBTYPE  SMOOTH  VEL  IS  VECT: 
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ADA  LANGUAGE  REFERENCE  MATERIALS 


During  the  course  of  this  project,  various  reference  materi¬ 
als  were  obtained  for  assistance  in  learning  the  Ada  language 
constructs  and  proper  usage.  These  materials  include  the 
following  books,  tutorials,  reference  manuals,  and  audio¬ 
visual  films.  Articles  may  be  found  in  the  bibliography. 

BOOKS: 

a.  Barnes,  J. ,  Programming  in  Ada,  Prentice-Hall,  Inc. 

1981 

b.  Hibbard,  P.,  et.  al..  Studies  in  Ada  Style,  Springer- 
Verlag,  1982 

c.  Ledgard,  H. ,  Ada  an  Introduction,  Springer-Verlag, 

Inc.,  1981. 

d.  Pyle,  I.,  The  Ada  Programming  Language,  Prentice-Hall, 
Inc.,  1982. 

e .  Wegner ,  P . ,  Programming  With  Ada:  An  Introduction  by 
Means  of  Graduated  Examples,  Prentice-Hall,  Inc., 

1979. 

TUTORIALS : 


a.  Massachusetts  Computer  Associates,  Low-Level  Language 
Features,  Cambridge,  Mass.,  1981. 

b.  Massachusetts  Computer  Associates,  The  Use  of  Ada 
Packages ,  Cambridge,  Mass.,  1980. 

c.  Massachusetts  Computer  Associates,  Tutorial  on  Ada 
Exceptions,  Cambridge,  Mass.,  1981. 

d.  Massachusetts  Computer  Associates,  Tutorial  on  Ada 
Tasking,  Volume  1:  Basic  Interprocess  Communication, 
Cambridge,  Mass.,  1981. 

e.  Massachusetts  Computer  Associates,  Type  Structures, 
Cambridge,  Mass.,  1981. 
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3.2.4 


ADA  LANGUAGE  REFERENCE  MATERIALS  (continued) 


REFERENCE  MANUALS: 

a.  U.  S.  Department  of  Defense,  Reference  Manual  for  the 
Ada  Programming  Language,  Washington,  D.  C.,  July,  1980. 

b.  U.  S.  Department  of  Defense,  Military  Standard-1815. 

Ada  Programming  Language,  Dec.,  1980. 

AUDIO-VISUAL  FILMS; 

a.  Honeywell/Alsys,  Ada  Programming  Course,  Presented 
by  Jean  Ichbiah,  John  Barnes,  and  Robert  Firth 
Minneapolis,  Minnesota,  1980. 

3.2.5  ADA  LANGUAGE  FINDINGS 

In  theory,  the  technology  transfer  which  has  produced  the 
unique  features  of  Ada  promises  a  radical  change  in  the 
traditional  software  development  process.  Features  and 
attributes  such  as  strong  typing,  packages,  tasks,  abstrac¬ 
tion,  and  information  hiding  have  implications  beyond  the 
programming  phase.  They  have  the  capability  of  forging 
and  influencing  both  the  software  design  and  system  design 
phases.  These  powerful  features  force  the  consideration  of 
program  structure  at  an  earlier  time. 

There  seems  certain  a  significant  amount  more  to  be  learned 
about  Ada's  viability  which  will  be  expedited  by  actual 
experience  with  a  validated  compiler.  Thus,  the 
eventual  acceptance  or  rejection  of  Ada  will  depend  on  the 
users.  A  number  of  points  and  issues  were  surfaced  during 
the  AN/TSQ-73  redesign  effort  which  other  Ada  users  will 
probably  experience  also.  These  include: 
a.  The  Need  for  User  Guidelines 

The  Ada  constructs  are  understood  well  enough,  but 
knowing  when  to  properly  apply  the  constructs  is  lacking. 
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3.2.5 


ADA  LANGUAGE  FINDINGS  (continued) 


The  reference  manual  does  not  offer  guidance  on  when  to 
apply?  for  example,  a  task  or  a  procedure.  There  have 
been  examples  cited  at  the  technical  exchanges  from 
the  AN/TSQ-73  that  could  be  either  a  task  or  a  procedure. 
The  conclusion  is  that  there  is  a  great  deal  to  be 
further  understood  about  the  proper  usage  of  Ada  con¬ 
structs.  Premature  usage  before  firm  guidelines  are 
established  to  confidently  apply  generics,  tasks, 
procedures,  and  packages  may  have  the  opposite  effect 
than  that  which  is  desired  in  the  development  and 
maintenance  phases.  This  approach  portends  awkward 
and  inefficient  software  structures. 

b.  The  Need  for  Overhead  and  Timing  Consideration  Data 
The  application  of  programming  constructs  for  real-time 
processing  requires  knowledge  of  which  timing  considera¬ 
tions  are  associated  with  the  various  Ada  constructs. 

In  addition,  the  overhead  associated  with  tasking  is 
necessary  to  confidently  apply  the  feature. 

c.  The  Need  for  Enhancing  Ada  as  a  System  Programming 
Language 

The  Ada  language  attempts  to  satisfy  two  traditional 
programming  environments:  system  and  applications. 

The  Ada  language  does  not  completely  satisfy  the  needs 
of  system  programming,  yet  it  offers  expanded  capability 
to  the  applications  programmer  by  having  system  respon¬ 
sibilities,  such  as  tasking.  The  major  problem  antici¬ 
pated  by  the  system  programmer  is  the  inability  of 
Ada's  high  level  constructs  to  address  the  real-time 
environment.  Specifically,  the  writing  of  an  operating 
system  or  kernal  scheduler  requires  more  capabilities 
than  the  Ada  language  provides.  These  capabilites 
include  the  ability  to: 

•  terminate  a  task 

•  kill  a  task 
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ADA  LANGUAGE  FINDINGS  (continued) 

•  ready  a  task 

•  suspend  a  task 

•  dequeue  a  task 

Interrupt  handling  requires  predefined  timing  requirements 
which  must  be  met  or  the  event  is  lost.  Ada  does  not  have 
this  capability. 

d.  Ada  Will  Require  Substantially  More  Educational  Training 
Than  Previous  Programming  Languages 

The  project  members  experienced  educational  training 
in  a  one  week  formal  course  and  access  to  Ada  language 
reference  materials  (3.2.4).  The  general  impressions 
were  that  learning  Ada  is  a  non-trival  task.  The 
sophistication  of  the  Ada  programming  language  features 
and  uniqueness  will  require  substantially  more  educational 
training  than  in  previous  programming  languages.  Both 
the  motivation  behind  the  concept  and  the  proper  applica¬ 
tion  needs  to  be  well  understood. 

It  appears  that  the  best  approach  is  to  proceed  from  the 
familiar  to  the  unfamiliar.  This  could  be  achieved  by 
two  Ada  courses.  The  first  (40  hours)  concentrating  on 
the  syntactical  composition  and  rudimentary  constructs 
found  in  familiar  languages  (eg.  Fortran,  Cobol) .  The 
second  course  (80  hours)  would  address  advanced  features 
and  novel  constructs  of  Ada.  This  course  should  include 
examples  from  military  examples.  The  courses  would  be 
separated  by  some  period  of  time  where  the  student  would 
have  access  to  the  Ada  films,  books,  computer  assisted 
courses,  and  a  computer  translator  to  proceed  at  the 
individual's  own  pace. 

As  with  other  learning  endeavors,  proficiency  can  be 
expected  to  be  a  function  of  language  usage  (experience) . 
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3.3 


PROJECT  TEAM  FACTORS 


To  realize  the  goals  from  the  redesign,  coding  and  docu¬ 
mentation  of  a  large  scale  software  system  using  the  Ada 
programming  language,  the  selection  of  the  project  team 
members  was  thorough  and  detailed.  The  factors  of  level 
of  education,  experience,  and  past  performance  were  scu- 
tinized  to  provide  the  required  level  of  expertise  and 
capability.  The  selected  career  types  had  to  qualify 
individually  and  have  a  high  degree  of  team  participation. 

An  emphasis  was  placed  on  team  effort  as  collective  ex¬ 
pertise  formulated  by  the  project  team  could  alleviate 
possible  problems. 

3.3.1  CAREER  TYPES  SELECTION 

In  the  selection  of  career  types,  the  following  prerequisites 
were  used  to  select  project  members: 

•  Knowledge  of  two  or  more  high  order  programming  languages. 

•  Coding  experience . 

•  Familiarity  with  the  basic  concepts  of  large  scale  soft¬ 
ware  systems. 

•  Some  system  design  experience. 

•  Demonstrated  communications  ability. 

The  selection  of  this  depth  and  level  of  experience  provided 
.  the  necessary  levels  of  career  types  to  fulfill  project  re¬ 
quirements.  The  following  subparagraphs  identify,  by  title, 
and  briefly  describe  the  career  types  which  were  utilized  for 
this  project. 

3. 3. 1.1  CAREER  TYPES  (TITLES) 

The  title  of  the  career  types  which  participated  on  this 
project  are: 

a.  Project  manager. 

b.  Principal  consultant. 
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CAREER  TYPES  (TITLES)  (continued) 

c.  Principal  programmer  analyst. 

d.  Principal  systems  analyst. 

e.  Senior  programmer  analyst. 

f.  Programmer  analyst. 

g.  Applications  programmer. 

h.  Software  systems  programmer. 

i.  Associate  applications  analyst. 

PROJECT  PERSONNEL 

The  following  subparagraphs  briefly  describe  the  individual 
career  types  which  participated  on  this  project: 

Project  Manager  -  Grade  Level  38 

Requires  experience  in  the  management  of  system  design, 
programming  projects,  in-depth  knowledge  of  system  design 
of  hardware/software,  program  design,  coding  and  testing 
and  in  the  preparation  of  reports  and  forms  associated 
with  major  government  projects. 

Principal  Consultant  -  Grade  Level  38 

Requires  expert  programming  knowledge  in  addition  to  a 
hiah  level  of  technical  expertise  in  automated  system, 
both  hardware  and  software.  Thorough  knowledge  of 
government  standards  and  procedures  is  mandatory. 

Principal  Programmer  Analyst  -  Grade  Level  15 

Requries  seasoned  experience  and  special  study  of  at  least 
one  major  applicatjon  system.  Expert  capability  with  at 
least  one  high  order  programming  language  and  a  programming 
background  sufficient  to  render  -'dgements  about  programming 
problems.  Also  requires  the  abi^..  y  to  evaluate  and  write 
programming  specifications  and  code. 
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PROJECT  PERSONNEL  (continued) 


Principal  Systems  Analyst  -  Grade  Level  15 

Requires  expert  knowledge  on  one  or  more  major  application 
fields,  including  theoretical  and  practical  aspects.  Thor¬ 
ough  familiarity  with  software  systems  and  programming  is 
required  and  the  ability  to  write  clear,  concise  system  speci 
fications  which  can  be  readily  translated  into  programmable 
code  is  required. 

Senior  Programmer  Analyst  -  Grade  Level  13 

Requires  thorough  knowledge  of  overall  functioning  of  soft¬ 
ware  systems  and  expert  knowledge  of  at  least  one  application 
system,  to  the  subsystem  level.  Must  have  expert  knowledge 
of  at  least  one  high  order  programming  languages  and  advanced 
familiarity  with  computer  operations. 

Programmer  Analyst  -  Grade  Level  11 

Requires  advanced  capability  with  at  least  one  high  order 
language  and  a  thorough  to  advanced  knowledge  of  computer 
operations.  Also  requires  general  to  thorough  understanding 
of  operating  systems  including  utility  routines,  subroutines, 
and  assembly  language  usage. 

Applications  Programmer  -  Grade  Level  11 

* 

Requires  advanced  programming  skills  in  at  least  one  language 
plus  thorough  capability  in  at  least  one  additional  languages 
Also  requires  thorough  knowledge  of  various  software  systems 
features  and  routines  and  must  be  knowledgeable  in  peripheral 
hardware . 

Software  Systems  Programmer  -  Grade  Level  11 

Requires  advanced  programming  ability  in  two  languages  and 
working  knowledge  of  various  software  systems  features  and 
routine.  Advanced  experience  with  operating  systems  and 
subroutines  is  also  required  for  this  position. 
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PROJECT  PERSONNEL  (continued) 

Associate  Applications  Analyst  -  Grade  Level  9 

Requires  general  knowledge  of  one  major  area  of  application 
and  general  programming  and  computer  operations  skills 
including  thorough  systems  analysis  skills.  Thorough  know¬ 
ledge  of  at  least  one  high  order  programming  language. 

PROJECT  FUNCTIONS 

The  career  types  listed  below  performed  the  described  func¬ 
tions  in  the  project: 

a.  Project  Manager  -  The  responsibility  for  overall  project 
integrity  was  vested  with  the  project  manager.  Specific 
tasks  included  submission  of  required  project  status  and 
accounting  reports,  coordination  and  assignment  of  re¬ 
sources,  final  review  authority,  and  principal  interface 
to  the  government  organization. 

b.  Prinicipal  Consultant  -  Provided  preliminary  data  on 
design  techniques  and  submitted  research  data  in  support 
of  deliverable  products;  design  plan,  final  report. 

Provided  analysis  services  for  design  methodology  vali¬ 
dation  and  source  code  review. 

c.  Principal  Systems  Analyst  -  As  the  technical  focal  point 
for  the  project  coordinated  individual  tasks  and  assign¬ 
ments,  reviewed  inputs  for  completeness  and  technical 
accuracy,  was  primarily  responsible  for  the  design 

plan  and  final  report,  and  was  the  principle  designer  for 
the  development  of  the  proposed  design  methodology  with 
direct  participation  in  data  assessment,  design  and  analysis 
techniques  and  technical  validation  of  project  findings. 

d.  Principal  Programmer  Analyst  -  Was  the  lead  participant 
in  the  design  methodology  validation  task.  Organized 
and  directed  the  program  coding  effort  to  ensure  delivery 
to  the  government  of  the  source  code  for  the  designated 
subfunction  of  the  Missile  Minder  System.  Provided  inputs 
for  both  the  design  plan  and  final  report. 
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PROJECT  FUNCTIONS  (continued) 


e.  Senior  Programmer  Analyst  -  Involved  in  the  development 
of  the  design  methodology,  with  primary  inputs  for  the 
design  techniques  of  system  entity  diagrams,  system 
design  language  and  structure  charts.  Was  a  participant 
in  the  program  coding  effort. 

f.  Programmer  Analyst  -  Primarily  dedicated  to  the  coding 
effort.  Was  the  recognized  project  authority  on  Ada 
programming  and  was  responsible  in  the  development  of 
the  source  code  for  the  selected  subfunction  of  the 
Missile  Minder  system.  Participated  in  the  validation 
effort  of  the  Ada  system  design  methodology. 

g.  Applications  Programmer  -  Was  a  major  contributor  in  the 
development  of  the  system  design  methodology.  Provided 
significant  inputs  to  the  design  plan  and  final  report. 
Worked  with  the  programmer  analyst  in  the  development 
of  the  source  code  for  the  selected  subfunction  of  the 
Missile  Minder  system. 

h.  Software  Systems  Programmer  -  Performed  in-depth  research 
and  analysis  into  the  design  techniques  as  expressed  in 
the  design  plan.  Participated  in  the  validation  effort 
of  the  Ada  system  design  methodology.  Provided  inputs 
for  both  the  design  plan  and  final  report. 

i.  Associate  Applications  Analyst  -  Responsible  for  all  data 
collection  and  recording.  Provided  computer  aided  design 
documentation  for  the  design  plan  and  final  report.  Was 
a  participant  in  the  validation  effort  for  the  Ada  system 
design  methodology. 


ADEQUACY  OF  PERSONNEL 


F« 


The  selection  of  project  personnel  was  derived  from  two  cate¬ 
gories  -  professional  discipline  and  project  peculiar  require¬ 
ments.  The  professional  disciplines  were  identified  to  provide 
the  best  cross  section  of  vertical  and  horizontal  expertise  in 
satisfaction  of  typical  programming  projects.  The  category  of 
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I  ADEQUACY  OF  PERSONNEL  (continued) 

project  peculiar  materialized  subsequent  to  careful  and 
in-depth  analysis  of  the  identified  individual's  actual 
experience  and  on-the-job  performance.  The  major  factors 
that  were  considered  included: 

•  Programming  experience,  based  upon  actual  coding  and 
results  achieved. 

•  Degree  of  familiarity  with  software  systems. 

•  Proven  ability  to  perform  original  design  work. 

•  Demonstrated  technical  writing  ability. 

•  Performance  as  "team"  player. 

•  Exposure  to  the  Ada  programming  language. 

There  was  a  recognized  overlap  of  functions,  but  this  was 
by  design  rather  than  exception.  The  individuals  originally 
selected  had  to  possess  the  quality  and  flexibility  to  per¬ 
mit  such  action.  Here  surfaces  the  exception  rather  than 
the  rule.  Typically  defined  career  patterns  would  not  permit 
such  a  luxuary,  however,  the  uniqueness  of  this  project 
directed  the  establishment  of  such  a  requirement. 

Project  manning  of  similar  efforts  would  not  require  this 
degree  of  flexibility,  however,  when  into  the  area  of  "new" 
territory  it  is  not  unrealistic  to  formulate  such  actions. 

It  was  concluded  that  the  adequacy  of  the  personnel  did  meet 
project  requirements  and  no  major  voids  of  expertise  were 
identified,  however,  the  following  findings  were  considered 
pertinent: 

a.  Top-level  design  work  should  be  assigned  higher  corporate 
level  personnel,  particularly  when  dealing  with  Ada  as  a 
programming  language. 

b.  The  Ada  language  requires  a  better  than  average  programmer. 

c.  In-depth  knowledge  of  Government  systems  and  familiarity 
with  the  use  of  Government  documentation  is  strongly 
recommended . 


1 


II-3-40 


3.4 


INSTRUCTIONAL  ISSUES 


Three  elements  of  the  project  were  identified  to  require 
formalized  instruction.  They  were  design  methodology 
(Structured  Analysis/Structured  Design) ,  Ada  Programming 
Language,  and  Missile  Minder  System  (AN/TSQ-73)  Indoctrin¬ 
ation.  From  this  base,  a  level  of  understanding  developed 
from  which  all  project  members  increased  their  degree  of 
expertise.  Informal  training,  which  was  primarily  derived 
from  books,  technical  journals  and  training  aids  such  as 
video  tapes,  supported  the  formalized  instruction.  All 
instructional  issues  had  the  underlining  objective  of 
providing  a  uniform  knowledge  base,  enhancement  of  design 
principles  and  increased  Ada  programming  skills. 

3.4.1  INSTRUCTIONAL  CURRICULUM 

All  formalized  instruction  followed  typical  lesson  plans 
and  course  outlines.  The  length  of  instruction  for  each 
was  forty  hours  with  the  exception  of  the  Missile  Minder 
Indoctrination  which  was  twenty-four  hours.  The  forty 
hour  courses  were  restricted  to  twenty-four  hours  of  stand- 
up  instruction  with  the  remaining  sixteen  hours  allocated 
to  workshop  sessions  and  small  group  discussions.  Reinforce¬ 
ment  documentation  was  available  for  all  three  subjects  to 
facilitate  problem  solutions  and  research  efforts.  Formalized 
instruction  provided  a  standardized  base  of  expertise, 
although  it  was  by  no  means  all  inclusive.  Extensive 
research  and  supplementary  reading  were  required  by  each 
individual  to  obtain  more  information  and  knowledge  on  speci¬ 
fic  subjects.  This  approach  allowed  each  team  member  to 
supplement  his/her  knowledge  for  particular  needs. 

3. 4. 1.1  DESIGN  METHODOLOGY 

A  design  approach  and  documentation  was  studies  from  a 
Structured  Analysis/Structured  Design  course  presented 
by  a  Control  Data  Consultant  from  the  Corporate's 
Consulting  and  Educational  Services  Division.  Textbook 
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DESIGN  METHODOLOGY  (continued) 


utilized  was  Structured  Analysis  by  Victor  Weinberg  sup¬ 
plemented  by  a  Control  Data  Corporate-developed  workbook  titled 
Structured  Analysis  and  Structured  Design  Syllabus.  The 
course  provided  project  members  with  the  disciplines 
required  to  evolve  the  current  design  methodology. 

ADA  PROGRAMMING  LANGUAGE 

The  formalized  course  of  instruction  for  Ada  programming 
was  locally  developed  and  presented  by  a  senior  level 
team  member  who  had  extensive  exposure  to  the  Ada  program¬ 
ming  language  including  practical  experience  in  early 
research  and  development  efforts.  The  objective  of  the 
course  was  to  introduce  the  Ada  programming  language  to 
project  members  from  which  they  could  build  a  working 
knowledge  of  the  language.  Supportive  documentation  for 
the  course  included: 

a.  The  Ada  Programming  Language  by  I.C.  Pyle. 

b.  Programming  With  Ada:  An  Introduction  bv  Means  of 
Graduated  Examples  by  P.  Wegner. 


3.4. 1.3  MISSILE  MINDER  INDOCTRINATION 

This  course  of  instruction  was  structured  from  information 
contained  in  the  development  specification  MI-PD19501,  FM 
44-70  (Field  Manual  for  all  Air  Defense  Artillery  Command 
and  Control  Systems,  AN/TSQ-73) ,  and  the  ACN  18006  (Interop 
III,  A-Technical  Feasibility). 

The  course  was  presented  by  a  Control  Data  Consultant  fam¬ 
iliar  with  the  Missile  Minder  System.  Subsequent  to  this 
instruction,  project  members  had  a  thorough  working  knowledge 
of  system  capabilities,  hardware/software  configurations, 
and  functional  composition. 
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4.1.4  INSTRUCTIONAL  ADEQUACIES 

As  previously  stated,  the  formalized  instruction  provided 
an  introductory  base  for  the  three  major  elements  of  the 
project  -  design  methodology,  Ada  programming  language, 
and  the  Missile  Minder  System  (AN/TSQ-73) .  The  very  con¬ 
cept  of  training,  however,  is  never  ending  and  for  any 
project  and/or  program  must  be  regarded  as  a  very  large 
function  of  the  effort.  The  paramount  objective  must  be 
to  raise  the  level  of  competence  and  understanding  of 
every  individual  in  the  organization  and  to  this  end  the 
training  must  be  dynamic  and  continuous.  From  the  viewpoint 
of  this  particular  project  the  following  opinions  are 
offered: 

•  Design  methodology  -  formalized  training  was  considered 
adequate,  however,  to  adequately  train  individuals  to  the 
level  of  implementation  of  the  various  techniques,  the 
amount  of  instructional  workshop  sessions  should  be  in¬ 
creased.  Restructure  of  the  courses  schedule  of  content 
would  be  expanded  to  sixty  (60)  hours  versus  the  current 
forty  (40) .  Also  as  the  project  progressed  four  to  eight 
(4  to  8)  hour  refresher  courses  to  intensify  individual 
levels  of  competence  would  be  beneficial. 

•  Ada  programming  language  -  thorough  knowledge  of  either 
PASCAL,  PL/1,  ALGOL  or  any  other  block  structured  lan¬ 
guage  is  a  definite  asset.  In  retrospect,  the  formalized 
course  of  instruction  of  only  forty  hours  was  considered 
insufficient  and  only  through  extensive  reinforcement 
knowledge  and  research  were  project  members  able  to  fully 
comprehend  the  full  concepts  of  this  programming  language. 
Once  ag  in,  in  retrospect  a  formalized  course  of  eighty 
hours  with  emphasis  placed  on  hands-on  programming  would 
have  served  the  project  goals  better.  Continuous  pro¬ 
gramming  exposure  must  be  afforded  all  concerned  indivi¬ 
duals  throughout  their  association  with  Ada  as  it  is  only 
through  actual  hands-on  training  will  increase  levels  of 
competence  be  realized.  Additional  adequate  reference 
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INSTRUCTIONAL  ADEQUACIES  (continued) 

materials  must  be  available  such  as  MIL-STD-1815 ,  however, 
it  was  found  that  Programming  in  Ada  by  J.  G.  P.  Barnes 
was  the  most  informative  and  beneficial. 

•  Missile  Minder  Indoctrination  -  the  instructional  period 
should  be  expanded  to  eighty  (80)  hours.  Subsequent  to 
the  formalized  instruction  project  members  were  introduced 
to  the  system,  however,  the  level  of  competence  required 
to  fully  appreciate  the  functions  and  concepts  of  the 
system  requires  more  time.  Extensive  reinforcement 
reading  is  mandatory  for  this  subject  and  adequate  and 
detailed  reference  materials  must  be  made  available  for 
all  concerned  individuals.  The  reference  materials 
recommended  are  stated  in  Paragraph  3. 4. 1.3. 
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CONCLUSIONS 


The  Ada  language  features  proved  beneficial  for  coding  a 
typical  military  application,  namely  a  section  of  the 
target  control  function  from  the  An/TSQ-73  (Missile  Minder) . 
The  more  sophisticated  features  such  as  packages,  tasks, 
task  types,  overloading,  and  strong  typing  found  efficient 
application  and  provided  significant  structuring  capability. 
The  task  types,  for  instance,  were  a  novel  mechanism  for 
allowing  one  task  for  each  of  the  twenty  sectors  processed 
by  a  typical  radar  sweep.  It  is  strongly  recommended, 
however,  that  to  guard  against  possible  misuse  and  assure 
proper  usage  of  the  powerful  constructs,  the  user  should 
have  thorough  educational  training  and  a  set  of  clear 
guidelines  for  applying  the  Ada  constructs.  This  will 
require  more  application  experiments  to  further  understand 
the  implications  inherent  in  the  usage  of  this  syntactically 
rich  language. 

The  Ada  language  is  a  large,  syntactically  rich  language 
and  consequently  learning  Ada  is  a  non-trival  task.  This 
becomes  a  more  serious  concern  when  one  considers  that  the 
eventual  acceptance  of  the  language  depends  on  the  users. 

Jft  seems  obvious  that  Ada  will  require  substantially  more 
educational  training  than  devoted  to  previous  programming 
languages.  Both  the  motivation  behind  the  concepts  as  well 
as  the  proper  application  needs  to  be  well  understood. 

Teaching  Ada  will  require  substantially  more  Ada  training 
than  was  devoted  to  traditional  languages.  This  will  re¬ 
quire  a  number  of  formal  courses  as  well  as  access  to  an 
Ada  translator/compiler,  self  paced  instruction  modes,  and 
audio-visual  media.  It  is  envisioned  that  a  series  of  Ada 
courses  will  be  necessary  for  individuals  to  adroitly  manip¬ 
ulate  the  powerful  features. 

The  Ada  language  has  demonstrated  the  capability  for  serving 
multiple  roles  (system  design  language,  program  design 
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4.0  CONCLUSIONS  (continued) 

language,  implementation  language) ,  and  can  support  a 
cohesive  software  system  design  methodology.  During 
the  AN/TSQ-73  redesign  effort,  such  a  methodology  was 
developed.  This  methodology  encompasses  a  series  of 
techniques  for  the  system  design  phase,  software  design 
phase,  and  programming  phase.  The  strength  of  this 
methodology  was  that  the  techniques  employed  were  both 
graphical  and  textual,  utilized  a  number  of  compatible 
structured  design  techniques,  were  mostly  automated, 
and  utilized  Ada  in  each  phase. 

• 

The  methodology's  techniques  at  the  system  design  phase 
experienced  the  most  evolution.  The  original  methodology 
was  composed  of  a  system  entity  diagram  and  a  system 
design  language.  The  SED  provided  a  logical  grouping  of 
functions  in  a  graphic  form,  earily  readable  by  both  the 
users,  analysts  and  programmers.  The  SDL  captured  infor¬ 
mation  including  system  objectives,  requirements,  capa¬ 
cities,  and  constraints  in  Ada  format.  Two  additional 
techniques  were  later  added  including  a  system  data  flow 
diagram  and  system  data  dictionary.  This  was  not  entirely 
unexpected  since  addressing  system  design  independent  of 
hardware/software  implementation  is  such  a  new  approach. 

These  additional  techniques  enhance  the  linkage  to  the 
software  design  phase  techniques,  especially  the  data  flow 
diagram  and  data  dictionary. 

Although  the  hardware/software  trade-off  analysis  was 
limited  during  this  project,  Control  Data  envisions  an 
iterative  process  between  the  system  level  techniques  and 
trade-off  analysis  until  requirements  are  adequately  developed 

The  system  design  language  captured  all  the  functions  neces¬ 
sary  to  define  the  system.  Based  on  the  guidelines  described 
in  MIL-STD-490,  an  Ada-based  SDL  is  a  viable  vehicle  for 
capturing  broad  requirements  and  detail  design.  The  design 
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specifications  appeared  easier  to  comprehend  than  traditional 
A- level,  B-level,  and  C-level  specifications.  The  system 
design  language  possesses  a  logical  structure,  sequence,  and 
non- redundancy  not  found  in  these  documents. 

As  the  contract  required  a  software  design  methodology,  the 
subsequent  phases  after  system  design  were  oriented  towards 
the  software  design  of  the  system  with  the  hardware  design 
more  of  a  mental  picture  than  a  formalized  structure.  As 
such,  before  a  unified  system  design  methodology  could  be 
firmly  established,  for  both  hardware  design  and  software 
design,  techniques  for  the  hardware  design  and  fabrication 
phases  need  to  be  established.  This  effort  would  most  likely 
further  define  the  techniques  necessary  at  the  system  design 
stage.  It  is  clear  from  the  AN/TSQ-73  redesign  effort, 
that  such  a  unified  system  design  methodology  must  make 
maximum  use  of  automated  techniques  lest  the  sheer  documen¬ 
tation  becomes  overwhelming. 

The  techniques  composing  the  software  design  phase  (data 
flow  diagrams,  data  dictionary,  and  structure  charts)  were 
proven  quite  adequate  and  cohesive  for  their  mission.  The 
structure  charts  proved  an  excellent  vehicle  for  transi¬ 
tioning  to  the  programming  phase's  program  design  language. 
Although  a  number  of  issues  have  been  addressed  under  this 
contract  concerning  Ada's  role  as  a  PDL,  this  remains  a 
promising  area  for  further  research.  There  exists  a  need 
to  finalize  the  requirements  which  will  define  an  Ada  pro¬ 
gram  design  language  (PDL) ,  and  how  these  requirements  can 
be  realized.  Finally,  from  a  methodology  viewpoint,  there 
remains  a  good  deal  more  to  be  understood  about  the  impact 
of  the  powerful  Ada  language  on  methods  of  design.  Further 
application  efforts  on  military  system's  requirements  appears 
to  be  the  viable  vehicle. 


4.0  CONCLUSIONS  (continued) 

The  Ada  language  clearly  has  the  capability  to  impact  more 
than  the  implementation  phase  of  the  software  system  life- 
cycle.  This  effect  is  because  the  language  embodies  features 
which  support  the  principles  of  encapsulation,  information 
hiding,  data  abstraction,  and  parallel  processing.  These 
qualities  are  actually  design  issues  and  naturally  invite 
experimentation  for  utilizing  Ada  as  a  design  language.  Ada 
was  applied  as  a  system  design  language  and  found  capable 
of  providing  informational  content  for  the  specification  of: 

a.  System  objectives. 

b.  System  entities,  subentities  and  their  relationships. 

c.  System  control,  data  flow  and  exception  handling. 

d.  System  requirements,  capacities,  and  constraints. 

This  was  accomplished  at  a  global  logical  level  before 
hardware  and  software  assignments  were  made. 

Ada  was  applied  as  a  program  design  language  and  found 
capable  of  creating  a  framework  for  the  code  and  supporting 
the  following  objectives: 

a.  Identifying  all  Ada  program  units  (PACKAGE,  TASK, 
PROCEDURE,  FUNCTION) . 

b.  Definition  of  logic  for  the  control  structures. 

c.  Parameter  definition  for  procedures  and  functions. 

d.  Global  data  definitions. 
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RECOMMENDATIONS 


The  automated  tools  used  to  support  the  software  design  meth¬ 
odology  were  based  upon  the  use  of  software  design  tools. 
However,  the  existing  automated  tools  that  were  used  in  the 
application  of  the  methodology  were  adopted  and  adapted  be¬ 
cause  a  full  complement  of  automated  tools  did  not  exist.  The 
limited  use  of  automated  tools  during  the  design  of  the  AN/TSQ 
73  convincingly  demonstrated  the  need  for  further  development 
of  software  design  tools  for  the  entire  design. 

The  program  design  and  coding  phase  consisted  of  two  subfunc¬ 
tions  -  Smoothing  and  Prediction.  These  two  subfunctions 
are  a  part  of  the  larger  sequence  (Tracking)  which  must  be 
completed  during  the  radar  scan.  Since  the  operation  of  the 
AN/TSQ-73  is  time  critical,  the  timing  aspects  should  be 
examined  in  greater  detail  to  determine  the  capability  of 
programs  written  in  Ada  to  meet  critical  timing  requirements. 

The  system  design  methodology  lends  itself  to  a  single 
baseline  that  can  be  generated  and  maintained  through 
the  use  of  automated  design  tools.  The  design  methodology, 
based  upon  Ada  as  a  system  design  language,  offered  sig¬ 
nificant  advantages: 

a.  Captures  all  the  requirements  in  a  single  baseline. 


b.  Avoids  duplication  of  requirements. 

c.  Can  be  automated  to  include  maintenance  and  distri¬ 
bution  of  changes. 

d.  Permits  early  hardware/software  trade-off  decisions. 

The  system  and  software  design  methodologies  presented  here¬ 
in  provide  a  viable  means  for  system  software  development 
and  should  be  utilized  as  one  of  the  Government's  design 
methodologies?  therefore,  it  is  recommended  that  the 
design  methodology  be  accepted.  To  further  enhance  the 
design  process,  the  following  actions  are  recommended: 
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RECOMMENDATIONS  (continued) 

a.  An  automated  software  design  system  for  the  total 
design  process  be  developed  based  upon  Ada  as  a 
design  language. 

b.  The  entire  tracking  sequence  be  programmed  in  Ada 
and  results  evaluated  against  a  set  of  representative 
target  reports  to  determine  adequacy  of  Ada  in  a  time 
dependent  system. 

c.  A  users  guide  be  developed  as  a  part  of  or  as  an 
adjunct  to  MIL-STD-18 15 . 

d.  The  system  design  process,  based  upon  Ada,  be  expanded 
to  include  the  hardware  design  including  simulation/ 
modelling,  and  computer  aided  design. 

e.  The  configuration  management  process  be  re-evaluated 
to  permit  development  of  the  specification  as  a  single 
baseline  based  upon  the  Ada  language. 

f.  A  set  of  software  management  techniques  be  developed 
to  act  as  production  control  mechanisms. 

Since  learning  Ada  will  require  substantially  more  Ada 
training  than  was  previously  devoted  to  programming  lan¬ 
guages,  it  is  recommended  that  a  graduated  Ada  curriculum 
be  developed.  A  minimum  of  two  forty  (40)  hour  courses 
covering  basic  and  advanced  topics  is  envisioned.  This 
educational  area  deserves  more  attention  from  researchers. 
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INTRODUCTION 


The  Ada  programming  language  is  a  significant  recent  effort 
initiated  by  the  Department  of  Defense  (DOD)  to  establish  a 
common  High  Order  Language  (HOL)  to  use  on  embedded  tactical 
military  systems.  It  has  been  designed  with  the  intent  of 
facilitating  a  marked  improvement  in  the  performance  of  em¬ 
bedded  computer  systems  and  addressing  software  deficiencies 
which  have  been  identified  in  numerous  studies  as  common 
impediments  to  such  systems. 

In  addition  to  the  development  of  a  high  powered  common  pro¬ 
gramming  language  (Ada) ;  the  need  for  compatible  software  system 
design  methods  has  also  been  recognized.  Currently,  no  system 
has  been  designed  or  coded  using  the  Ada  language.  Yet,  to 
effectively  evaluate  and  analyze  the  full  impact  of  the  Ada 
programming  language  relative  to  software  system  design,  an 
actual  system  design  must  be  attempted.  Therefore,  the  U.S. 

Army  at  Fort  Monmouth  (specifically  the  Center  for  Tactical 
Computer  Systems  (CENTACS) ) ,  has  initiated  contractual  research 
and  development  design  efforts  to  acquire  information  concerning 
large  scale  software  system  design  related  to  utilizing  the 
Ada  language  efficiently. 

Associated  with  various  Ada  language  activities.  Software  Tech¬ 
nology  Division,  CENTACS,  is  seeking  to  establish  software 
design  methods  which  are  compatible  with  the  Ada  language. 

In  addition  to  the  design  issues  expected  to  surface  during 
this  effort,  information  is  being  sought  to  develop  a  total 
educational  training  program  for  various  skill  level  personnel 
to  effectively  employ  the  Ada  language. 

The  Ada  R&D  redesign  efforts  will  provide  Ada  system  design 
experience  for  use  in  developing  a  curriculum  and  materials 
for  training  in  using  Ada  as  a  system/program  design  language 
and  as  an  implementation  language.  This  information  should 
result  from  the  combination  of  a  design  methodology  analysis 
and  then  applying  the  results  to  a  large  scale  software  system 
design. 
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The  objective  of  this  designer's  guide  is  to  present  a  descrip¬ 
tion  of  the  design  methodology  to  be  utilized  by  Control  Data 
Corporation  project  personnel  for  the  software  system  design  of 
the  AN/TSQ-73  Missile  Minder  using  the  Ada  programming  language 
under  contract  number  DAAK80-81-C-0107 .  This  document  was  devel¬ 
oped  to  explain  the  rationale  for  selection  and  delineation  of 
the  methods  and  standardized  usage  by  the  project  team  members. 
Additional  information,  especially  concerning  design  issues 
encountered  and  lessons  learned  on  this  project  will  be  delivered 
in  the  final  report  (contract  CDRL  C002) .  The  methodology  goal  is  to 
establish  a  framework  of  Ada  compatible  techniques  which  are  linked 
to  and  facilitate  the  evolution  of  software  exhibiting  high  re¬ 
liability  and  subsequently  increased  maintainability.  As  a 
result  of  the  application  of  these  techniques  during  the  redesign 
of  the  TSQ-73  system  using  Ada,  it  is  anticipated  that  recommen¬ 
dations  will  emerge  to  enhance  the  methodology  contained  within 
this  document. 

The  guide  is  organized  into  the  following  sections: 

Introduction 

-  Statement  of  the  Military's  Problem 
Rationale  for  Software  System  Design  Methodology 
Software  System  Design  Methodology  Overview 

The  Software  System  Design  Methodology  Components 
System  Entity  Diagram 
System  Design  Language 
Data  Flow  Diagrams 

-  Data  Dictionary 
Structure  Charts 
Program  Design  Language 

-  Program  Complexity  Measure 
Structured  Programming 

Design  Reviews  and  Walkthroughs 

Summary 

Appendix  A  (Program  Design  Methodology  Reviews) 

Appendix  B  (References) 
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STATEMENT  OF  THE  MILITARY 1 S  SOFTWARE  PROBLEM 


The  two  central  problems  with  the  tactical  software  component 
of  military  computer  embedded  systems  are  the  same  as  with  soft¬ 
ware  in  general  -  cost  and  reliability.  However,  since  the 
Department  of  Defense  is  by  far  the  largest  single  consumer  of 
software  and  related  products,  the  problems  are  especially  large 
and  complex.  The  following  facts  are  from  recent  DOD  and  Army  studies. 

1.  Studies  conducted  in  1973  and  1974  give  conservative 
estimates  for  lower  bounds  on  DOD  software  costs. 

Figure  1  indicates  the  breakdown  of  the  estimated  $3 
billion  annual  DOD  software  costs.  More  than  one- 
half  of  these  costs  are  associated  with  embedded  com¬ 
puter  systems  written  in  five  hundred  (500)  general 
purpose  languages.  Embedded  computer  software  often 
exhibits  characteristics  that  are  strikingly  different 
from  those  of  other  computer  applications.  The  pro¬ 
grams  are  frequently  large  (50,000  to  100,000  lines 

of  code)  and  long-lived  (10  to  15  years) .  Personnel 
turnover  is  rapid,  typically  two  years.  Change  is 
continuous  because  of  evolving  system  requirements, 
and  annual  revisions  are  often  of  the  same  magnitude 
as  the  original  development. 

2.  The  majority  of  military  costs  spent  on  computer  systems 
is  in  the  software  arena  and  this  amount  is  growing  in 
proportion  to  other  computer  costs.  Figure  2  clearly 
indicates  that  the  rise  in  software  development  costs 

is  as  significant  as  the  reduction  in  hardware  costs. 

Notice  also  the  rise  in  the  proportion  of  software  main¬ 
tenance  costs,  now  the  single  most  expensive  phase  in 
the  software  life-cycle.  It  is  not  unreasonable  and, 
in  fact,  quite  common  to  say  that  70%  of  the  life-cycle 
costs  occur  in  the  maintenance  phase. 
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Figure  2  -  Hardware  Software  Cost  Trends 


3.  A  recent  Army  Post  Deployment  Software  Support  (PDSS) 
study  revealed  that  the  Army  employed  a  minimum  of  59 
different  computer  types  from  29  diverse  manufacturers. 

Software  was  found  to  be  written  in  10  higher  order 
languages  and  approximately  32  machine-oriented  languages. 

These  proliferation  problems  have  a  multiplying  effect 

on  costs  for  management  and  technical  activities  ranging 
from  personnel  training  through  technical  documentation. 

4.  Unfortunately,  the  future  projections  of  DOD  expenditures. 

Figure  3,  reveal  even  more  alarming  trends  than  previ¬ 
ous  studies  (4) .  This  graph  illustrates  that  as  the 

DOD  budget  increases  2.8  times,  the  software  price 
increases  8.1  times.  Clearly,  management  and  technical 
issues  relating  to  software  methodology  and  productivity 
must  be  surfaced  and  addressed. 

In  addition  to  cost  concerns,  studies  have  also  revealed  software 
reliability  as  a  second  major  area  for  software  difficulties. 
Reliability  should  be  viewed  as  far  more  than  quantitative  Mean 
Time  Between  Interruption  (MTBI)  statistics  or  automated  recovery 
from  a  hardware  failure.  Software  reliability  is  a  function  of 
the  difficulties  a  particular  software  system  causes  for  the  users. 

A  software  system  would  have  high  reliability  if  it  satisfied  the 
initial  requirements,  performed  to  the  users  satisfaction,  and  was 
designed  for  change  and  accountability.  Unfortunately,  this  is 
rarely  the  case.  Reliability  spans  the  entire  software  life-cycle 
from  design  through  maintenance  and  is  the  primary  culprit  respon¬ 
sible  for  excessive  costs  (7,8).  The  high  costs  of  software  for 
defense  systems  are  a  symptom  of  poor  reliability.  This  poor 
reliability  is  partially  a  result  of  language  proliferation.  But, 
in  addition,  recent  studies  indicate  a  strong  correlation  between 
software's  structural  composition  and  the  amount  of  errors  encountered 

The  foremost  key  to  software  reliability  is  the  degree  of  precision 
and  accuracy  achieved  during  the  initial  system  life  cycle  phases 
of  requirements/specifications  and  design  (Figure  4) .  It  is  these 
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Figure  3  -  Defense  Computer  Expenditures  Till  1990 
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System  Life-Cycle  Phases 


phases  which  have  the  greatest  impact  on  the  overall  efficiency 
of  the  system  and  consequently,  the  overall  cost.  This  point 
cannot  be  over-emphasized.  The  requirements/specifications  phase 
must  reflect  a  complete  and  unambiguous  statement  of  the  problem 
to  be  solved.  The  design  phase  must  fit  a  solution  to  the  pre¬ 
viously  defined  problem.  In  addition,  the  system  software  should 
be  designed  to  facilitate  testing  efforts  and  not  to  constrain 
the  impact  of  the  inevitable  change.  What  is  needed  is  a  method¬ 
ology  for  software  system  development  which  makes  the  concern  for 
reliability  an  integral  part  of  the  development  process,  especi¬ 
ally  in  the  design  phase.  Careful  attention  should  be  paid  to 
those  methods  which  address  the  early  phase  of  development  and 
which  are  strongly  linked  to  testing/validation  and  maintenance 
efforts. 

One  promising  avenue  of  attacking  these  central  problems  is  by 
reducing  the  proliferation  of  languages,  with  the  ultimate  goal 
of  standardization  on  one  high  order  advanced  language  possessing 
sophisticated  facilities  which  address  tactical  requirements. 

The  Department  of  Defense  directives  (5,6)  are  clearly  aimed  at 
the  reduction  of  proliferation  to  a  small  set  of  approved  languages. 
The  result  has  been  the  development  of  one  standard  programming 
language  for  embedded  computer  systems.  This  language  is  known 
as  Ada.  Ada's  data  abstraction  capability,  modularity,  block 
structure,  single  entry-single  exit  control  constructs,  embedded 
program  documentation,  and  finally  specification/implementation 
section  separation  should  enhance  the  production  of  more  reliable 
tactical  system  software  and  programmer  maintenance  efforts.  Addi¬ 
tionally,  the  unique,  dynamic  exception  handling  capability,  along 
with  real-time  access,  parallel  processing  capability,  and  low 
level  I/O,  provide  real-time  control  constructs  not  previously 
found  in  high  order  languages.  These  language  features,  utilized 
within  the  Ada  Programming  Support  Environment  (APSE)  should  help 
reduce  support  costs  and  more  closely  fit  the  requirements  of 
military  systems  than  do  previously  available  languages  and  weak 
support  environments  when  available. 
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The  advantages  promised  by  standardizing  on  one  language  include 
the  following: 

1.  Since  the  programming  language  pervades  all  phases  of  the 
software  life-cycle,  it  will  play  a  substantial  role  in 
how  well  the  computer  system  fulfills  original  ambitions. 

2.  The  limiting  of  programming  languages  will  allow  greater 
focusing  and  achievments  by  research  efforts  in  developing 
support  tools,  common  library  facilities,  and  training 
methods. 

3.  Language  proliferation  reduction  fosters  the  creation  of 
centralized  centers  of  expertise  which  could  provide  a 
development  and  maintenance  environment  which  could  be 
shared  by  various  tactical  systems  to  reduce  cost  and 
increase  reliability. 

It  should  be  pointed  out,  however,  that  despite  the  large  positive 
step  forward  due  to  standardizing  on  a  powerful  software  language 
and  support  environment,  there  remains  other  accompanying  factors 
which  must  be  addressed.  The  achievement  of  reliable  embedded 
computer  systems  software  without  excessive  cost  is  determined  not 
only  by  the  utilization  of  a  particular  language  and  its  support 
environment,  but  also  their  utilization  in  conjunction  with  a 
system  design  methodology,  and  a  commitment  from  management  to 
the  educational  training  and  project  time  necessary  to  bring  the 
components  to  bear.  It  is  through  employment  of  these  evolving 
components  that  reliable  and  cost  effective  software  systems  can 
be  realized  (Figure  5) . 

This  guide  addresses  the  establishment  of  a  system  design  method¬ 
ology  developed  from  a  software  engineering  viewpoint.  It  has 
been  designed  to  be  compatible  with  both  the  Ada  language  and  the 
demands  of  large  scale  software  system  construction. 


Figure  5  -  Components  of  Reliable  Software 


Source:  T.  Walsh,  P.  Texel  (17,  18) 


RATIONALE  FOR  A  SOFTWARE  SYSTEM  DESIGN  METHODOLOGY 


The  diificulties  associated  with  the  process  of  systems/software 
analysis,  development  and  maintenance,  accompanied  by  the  related 
side-effects  of  low  reliability  and  excessive  cost  described  in 
the  previous  section  are  ample  incentives  for  a  strong  response 
in  the  problematic  area  of  software  design.  The  term  software 
engineering  is  representative  of  the  forum  for  responsiveness  and 
mastery  of  this  problematic  area.  Although  software  engineering's 
mission  is  quite  broad,  it  includes  the  creation  of  a  set  of 
techniques  sharing  a  natural  affinity  and  linked  by  a  common 
theme  known  here  as  a  software  system  design  methodology. 

The  importance  and  need  for  a  software  system  design  methodology 
has  been  thrust  upon  the  computer  world  via  the  escalating  soft¬ 
ware  production  and  maintenance  costs.  Furthermore,  since  large 
software  system  development  projects  with  significant  numbers  of 
embedded  components  cannot  be  comprehended  by  any  one  individual, 
it  is  essential  to  create  a  communicative  framework  as  a  common 
reference  for  all  project  members.  Especially  in  the  computer 
field  it  should  be  expected- that  personnel  turnover  will  constantly 
result  in  new  personnel  who  will  become  more  productive  sooner  with 
a  communicative  framework.  Lastly,  cognizance  of  the  numerous 
failures  ad  hoc  design  has  produced  in  the  past  is  ample  incentive 
for  seeking  assistance  from  viable  tools,  techniques  and  methods. 

There  is  a  strong  tendency  in  the  data  processing  world  to  tout 
all  new  methods,  tools,  and  techniques  as  the  ultimate  cure-all 
for  computer  ills.  A  corollary  naturally  being  that  all  previous 
advances  are  rendered  obsolete.  The  reader  in  the  literature  may 
also  be  troubled  by  semantics.  Confusion  is  rendered  by  the 
constant  introduction  of  new  terms  or  words  which  possess  multiple 
definitions.  Comparisons  of  different  methodologies  and  complete¬ 
ness  checks  become  at  best  difficult.  Finally,  there  are  many 
questions  concerning  the  elements  of  good  system  and  software 
design  that  presently  remain  unanswered  in  software  engineering. 


At  present,  the  pragmatic  system  builder  is  faced  with  the  sub¬ 
stantial  challenge  of  modifying  and  extending  existing  tools  and 
techniques  in  a  unique  combination  for  the  specific  project  at 
hand.  The  pragmatic  system  builder  should  be  comforted  by  the 
thought  that  it  is  not  necessary  to  achieve  perfection  in  the 
year  1982,  but  to  synthesize  the  best  collection  of  techniques 
as  a  practical  baseline  for  present  system  development  and 
future  technical  enhancement.  This  guide  represents  such  an 
effort  for  the  large  scale  software  system  design  of  the  AN/TSQ-73 
Missile  Minder  using  the  Ada  programming  language. 

The  approach  to  be  taken  for  constructing  a  software  system  design 
methodology  is  based  on  lessons  learned,  analytical  studies,  and 
successful  practices  in  the  rapidly  emerging  field  of  software 
engineering.  The  following  key  principles  which  are  somewhat 
interdependent,  form  the  underpinning  for  Control  Data's  software 
system  design  methodology: 

1.  Life  Cycle  View  -  Software  systems  evolve  through  various  stages 
of  development.  During  the  initial  phase  of  requirements/speci¬ 
fications,  the  problem  is  defined  and  analyzed.  The  design 
phase  follows  and  is  responsible  for  translating  the  problem 
and  its  requirements  into  a  blueprint  of  the  actual  solution. 
Once  the  design  representation  is  complete,  implementation 
begins  and  the  conceptual  solution  from  design  is  transformed 
into  a  computer-processable  form.  The  testing  phase  follows. 
Using  the  requirements  as  a  baseline  for  which  errors  are 
measured,  a  search  is  made  for  design  errors  and  programming 
errors,  and  the  program  is  put  into  final  form.  The  final 
stage  in  the  life  cycle  is  maintenance.  Empirical  studies 
have  shown  the  need  and  advantages  for  techniques  in  all  stages 
especially  the  initial  phases  of  requirements,  specifications 
and  design  where  surfacing  errors  will  pay  the  richest  divi¬ 
dends  (19,  20,  21). 
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Levels  of  Abstraction  -  One  of  the  most  strategic  mental  tools 
for  dealing  effectively  with  complexity  is  the  power  of  abstrac¬ 
tion  (22-26) .  The  abstraction  process  describes  or  emphasizes 
some  of  the  more  important  details,  properties,  or  parts,  while 
delegating  others  into  a  background  that  will  be  expressed 
later.  When  this  approach  is  executed  properly,  the  resulting 
structure  has  minimum  complexity  and  highly  independent  levels. 
The  first  level  of  abstraction  typically  contains  little  or 
no  detail,  it  is  simply  a  capsule  description  of  what  the  system 
is  or  does.  At  each  successive  level  more  detail  is  added  to 
the  abstraction  of  the  previous  level  until  ultimately,  at  the 
lowest  level,  all  details  of  the  system  have  been  captured. 

Isolation  of  Detail  -  The  ability  to  isolate  detail  or  perform 
information  hiding  (26)  is  related  to  levels  of  abstraction. 
Details  or  knowledge  pertaining  to  data  structures,  algorithms, 
or  resources  can  be  hidden.  Users  desiring  a  high  level  view 
of  the  system  can  do  so  only  if  these  levels  exist.  Otherwise, 
they  would  be  distracted  by  the  enormous  amount  of  detail 
present  at  the  lower  level.  By  implementing  a  number  of  levels 
of  abstraction,  users  with  different  needs  can  get  the  concep¬ 
tual  view  of  the  system  that  reveals  the  level  of  detail  they 
desire.  Additionally,  the  levels  of  abstraction  provide  a 
vehicle  to  understand  large  scale  systems  in  a  manner  compatible 
with  human  comprehension.  One  can  view  the  forest  before 
examining  the  trees. 

Finite  Human  Capability  -  Human  beings  possess  very  limited 
processing  skills  of  logical  structures  and  need  quantitative, 
graphical  and  automated  assistance  to  increase  precision.  All 
techniques  must  aim  to  keep  the  design  within  the  constraints 
of  human  understanding  (27,  28) . 


Graphical  Communications  -  The  value  of  graphics  should  not 
be  underestimated  as  a  communication  mechanism  that  may  convey 
a  great  deal  of  information  very  quickly  (29) .  Pattern  recog¬ 
nition  often  reveals  emissions,  redundnacy,  and  awkwardness. 


Program  design  when  offered  in  graphical  form  has  the  following 
advantages  over  its  textual  equivalent: 

•  Interfaces  between  components  enjoy  higher  visibility. 

•  Structural  characteristics  are  expressed  more  concisely 
and  are  less  ambiguous. 

•  Graphics  are  superior  in  expressing  the  flow  oriented 
process . 

•  Psychological  studies  indicate  that  the  graphical  vehicle 
of  communication  is  more  readily  comprehendible . 

6.  Automated  Techniques  -  Recent  software  engineering  advances 
indicate  the  strong  viability  of  the  automation  of  design 
tools  sometimes  known  by  the  acronym  CAD  (Computer  Aided 
Design)  to  support  the  human  design  process.  These  tools 
possess  the  capability  to  greatly  boost  design  productivity 
and  enhance  the  limited  human  design  capability.  A  large  bene¬ 
fit  derived  from  automated  design,  via  textual  and  graphical 
representations,  is  in  the  hours  saved  by  letting  the  computer 
produce  and  record  the  readable  documentation.  The  computer 
can  historically  save  all  the  design  documents  and  readily 
make  them  available  during  the  entire  life  cycle  (including 
maintenance) .  Software  engineering  studies  would  have  a  ready 
made  data  base  and  management  would  be  provided  with  clear 
windows  of  visibility  and  accountability. 

7.  Human  Communications  -  The  major  role  of  documentation  is  to 
foster  human- to- human  communications.  The  failure  of  humans 
to  communicate  properly  is  the  source  of  many  computer  errors, 
especially  on  large  systems.  Written  documentation  is  the 
primary  means  by  which  different  project  personnel  communicate 
as  the  system  evolves  through  time.  Such  documentation  can  be 
represented  in  either  textual  or  graphic  format. 
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8.  User  Friendliness  -  The  psychology  of  the  human  user  must 

be  a  consideration  in  the  proposal  of  any  design  methodology 
techniques  (30) .  The  arrival  at  a  certain  design  methodology 
technique  should  only  come  after  an  understanding  of  human 
perceptual  skills,  decision  making  ability,  cognitive  styles, 
and  information  processing  capacity.  The  techniques  should 
relieve  the  user  of  any  of  the  unnecessary  chores  inherent 
in  system  design,  should  have  ample  provisions  for  corrections, 
and  above  all,  should  be  easy  to  understand.  The  user  should 
feel  comfortable  with  their  usage  and  be  positively  encouraged 
that  the  aids  have  made  the  job  easier  and  more  rewarding. 

User  friendliness  is  an  underlying  principle  in  motivating 
computer  personnel  and  increasing  productivity. 

9.  Simplicity  -  Design  methodology  techniques  should  be  based  on 
"deep  simplicities"  so  that  they  can  be  properly  and  effec¬ 
tively  utilized.  As  is  stated  in  Structured  Programming  (31) , 
"Good  program  design  finding  deep  simplicities  in  a  complex 
logical  task-leads  to  work  reduction.  It  can  reduce  a  500- 
line  program  that  makes  sense  line-by-line  to  100  lines  that 
make  sense  as  a  whole.  Good  design  can  reduce  a  50,000  line 
program  impossible  to  code  correctly  to  a  20,000  line  program 
that  runs  error  free". 

0.  Software's  Mathematical  Nature  -  There  has  been  an  increasing 
awareness  that  software  is  basically  mathematical  in  nature. 

As  Dijkstra  states  (32) ,  "I  regard  programming  as  one  of  the 
more  creative  branches  of  applied  mathematics  and  the  view 
of  a  program  as  an  abstract  mechanism  makes  it  perfectly  clear 
that  designing  will  play  an  essential  role  in  the  activity 
of  programming" . 

Thus,  these  key  prir  ’iples  have  shaped  the  software  system  design 
methodology  which,  in  turn,  determines  the  techniques  which  support 
the  methodology.  Figure  6  illustrates  the  adherence  of  the  proposed 
techniques  of  the  software  system  design  methodology  with  the  stated 
guiding  principles. 
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THE  SOFTWARE  SYSTEM  DESIGN  METHODOLOGY  OVERVIEW 


The  guiding  principles  as  set  forth  in  the  previous  section  form 
the  foundation  upon  which  the  methodology  rests.  This  overview 
briefly  describes  three  phases  of  development,  the  eight  techni¬ 
ques  of  the  design  methodology  and  the  approach  taken  in  selecting 
the  methodology.  Details  of  the  individual  techniques  are  dis¬ 
cussed  in  the  following  sections  of  this  plan. 

The  Ada  compatible  software  system  design  methodology  described  in 
this  document  has  been  derived  from  the  program  design  methodologies 
review  whose  contents  are  found  in  Appendix  A  and  from  the  literature 
references  found  in  Appendix  B.  Some  of  the  objectives  of  this 
evolving  and  utilized  design  methodology  are: 

1.  Supports  the  more  difficult  system  architecture  design  process 
which  include  hardware  design  occuring  concurrently  with  soft¬ 
ware  design. 

2.  Utilizes  the  concept  of  levels  of  abstration  within  the  system 
design  phase  and  portions  of  the  software  design  and  coding 
phases  to  clearly  view  systems  at  different  developmental  levels 
and  provides  a  mechanism  for  accountability  and  traceability 

of  system  requirements  as  they  are  mapped  through  various  design 
representations  to  final  implementation. 

3.  Supports  clear  and  concise  description  and  communication  of  the 
design  between  human  beings  by  utilizing  graphic  tools  where 
possible . 

4.  Supports  automated  tools  to  free  human  designers  from  tedious 
and  painstaking  efforts  during  the  representation  of  their 
design  constructs. 

In  order  to  facilitate  further  understanding  of  these  objectives, 
they  must  be  explained  in  more  detail. 

As  the  result  of  technological  advances  in  recent  years,  it  is  now 
quite  advantageous  from  a  reliability  and  system  cost  point  of  view 
to  take  a  significantly  different  approach  to  system  construction. 
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These  advances  have  reversed  the  hardware  and  software  cost  percen¬ 
tages  of  the  total  system  costs.  Figure  2  of  this  document  illus¬ 
trates  this  point  nicely.  Traditionally,  system  construction  has 
been  highly  biased  toward  hardware.  Hardware  decisions  relating 
to  specifications  and  actual  acquisition  took  place  prior  to  soft¬ 
ware  considerations  (Figure  7) .  This  approach  was  well  suited  for 
the  time  when  hardware  costs  represented  the  overwhelming  majority 
of  the  system  costs.  Today,  however,  there  are  many  disadvantages 
of  this  approach. 

This  hardware  approach  is  naturally  biased  toward  hardware  solutions. 
However,  hardware  medium  is  not  as  flexible  as  software  to  the  in¬ 
evitable  changes  that  occur  as  systems  evolve.  Unnecessary  system 
complexity  is  often  built  in  by  the  hardware  constraint.  The  end 
result  of  treating  hardware  and  software  independently  increases  the 
software  difficulties,  especially  during  the  integration  period, 
because  the  burden  of  compatibility  is  placed  squarely  on  software. 

It  seems  reasonable,  especially  in  light  of  cost  data,  that  an  inter¬ 
dependent  view  of  hardware/software  should  be  taken  when  generating 
initial  design  in  response  to  system  requirement  specifications. 

Thus,  the  major  functions  of  a  system  should  be  identified  and 
described  independent  of  their  eventual  implementation  in  hardware 
or  software.  This  can  result  in  better  system  engineering,  correct¬ 
ness,  controls,  disciplines,  traceability  and  modularity.  If  such 
qualities  are  present,  the  accountability  is  simplified  in  tracing 
the  technical  links  when  the  system  requirements  architectures  become 
hardware  and  software  requirements  architecture.  The  dividends  in 
the  maintenance  phase  should  become  significant.  Hence,  a  major 
goal  of  the  methodology  is  to  address  the  system  architecture  descrip¬ 
tion  process  as  well  as  the  software  program  architecture  process. 

Another  major  goal  op  objective  is  to  utilize  the  levels  of  abstrac¬ 
tion  concept  within  the  methodology  techniques,  especially  in  the 
system  design  phase,  to  build  and  view  systems  at  various  logical 
levels.  The  abstraction  process  allows  for  clear  communication  and 
separation  of  functional  facilities  from  the  implementation  of  those 
features.  This  is  accomplished  by  a  series  of  abstract  levels. 
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Each  level  should  be  as  highly  independent  from  previous  and  suc¬ 
ceeding  levels  as  possible.  Succeeding  levels  should  add  more 
details  and  preceeding  levels  should  characterize  information 
hiding.  The  motivation  here  is  to  minimize  system  complexity 
and  facilitate  human  comprehension  of  the  system's  contents.  The 
field  of  mathematics  has  long  used  this  process  to  master  complex¬ 
ity  and  seek  more  powerful  and  general  consistency  (33,  34).  Levels 
of  abstraction,  of  course,  serve  as  a  further  description  strati¬ 
fication  of  the  proposed  hardware/software  solution.  At  the 
highest  level  of  abstraction,  the  overall  view  of  the  system  is 
simply  stated.  At  each  successive  level,  additional  details  become 
apparent  until  at  the  lowest  level  one  finds  all  the  details  required 
for  decision-making  or  implementation. 

As  computer  aids  in  the  form  of  graphic  tools  and  storage  mediums 
are  available,  their  use  is  encouraged  to  provide  information  on  the 
usefulness  of  computer  automation  for  the  production  of  both  design 
and  accompanying  documentation.  Automated  representation  at  each 
methodology  step/technique  lends  itself  to  greater  control  of  main¬ 
tenance  changes  which  in  turn  could  influence  future  configuration 
management  techniques.  The  quantity  of  documentation  associated 
with  large  system  construction  can  best  be  handled  by  automated  tools. 

As  stated  previously,  the  approach  to  software  system  design  advocated 
in  this  document  is  to  generate  hardware  and  software  specifications 
in  unison.  This  is  accomplished  by  the  usage  of  high  level  techniques 
known  as  System  Entity  Diagrams  and  a  System  Design  Language  within 
the  System  Design  Phase.  Once  these  techniques  have  described  the 
system  functions,  empirical  evaluation  schemes  can  selectively  choose 
which  features  may  best  be  accomplished  by  both  hardware  and  software 
(Figure  8).  It  is  anticipated  that  such  factors  as  cost,  performance, 
and  schedules  would  play  a  significant  role  in  this  selection  activity 
when  systems  are  new  and  in  the  conceptual  stage. 

The  major  advantage  of  describing  hardware  and  software  functions  in 
unison  is  that  it  brings  the  software  engineering  perspective  to  the 
system  level.  This  should  serve  to  reduce  system  complexity  by 
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allowing  for  system  solutions  independent  of  eventual  implementation 
mediums.  It  also  establishes  a  framework  for  the  levels  of  abstrac¬ 
tion  philosophy  for  the  parallel  development  paths  of  hardware  and 
software.  Literature  support  for  this  innovative  approach  may  be 
found  in  references  35  and  36.  As  Figure  9  indicates,  the  software 
development  process  then  continues  with  unique  steps  composed  of 
techniques  until  the  actual  code  is  fully  described  and  integrated. 
Refer  to  Figure  1C  for  an  illustration  of  development  phases  and 
steps. 

The  software  system  design  of  the  TSQ-73  project  will  proceed  in 
the  manner  as  depicted  in  Figure  9.  The  design  of  large  scale  mili¬ 
tary  tactical  systems  should  begin  with  a  conceptual  view  of  the 
system  as  a  whole  remaining  independent  of  hardware  and  software. 

This  view  is  accomplished  with  the  System  Entity  Diagram,  the  first 
step.  Graphical  in  nature,  the  system  entity  diagram  allows  for 
the  functional  decomposition  of  the  system  at  the  highest  level. 

In  the  automated  form,  it  provides  a  user  friendly  method  of  gener¬ 
ating  the  initial  stages  of  the  system  design.  The  implementation 
of  these  processes  may  eventually  be  hardware,  software,  manual  or 
some  combination  thereof.  The  SED  function  is  supported  using  the 
System  Design  Language. 

Although  the  SED  could  theoretically  contain  n  levels  of  entities, 
it  was  decided  that  the  TSQ-73  project  could  be  limited  to  six. 

This  decision  was  made  for  two  reasons.  First,  the  complexity  of 
the  missile  minder  system  was  intuitively  felt  to  warrant  a  maximum 
of  six  levels.  Second,  the  usage  of  an  SDL  technique  is  brand  new, 
yet  a  high  degree  of  confidence  abounded  that  its  Ada-based  contructs 
could  adequately  support  the  continuation  of  the  SED  process  and  add 
additional  details. 

Supporting  the  system  entity  diagram  is  the  system  design  language, 
the  second  step.  The  system  design  language  (SDL)  techniques 
explains  the  functions  in  processor-independent  logic  based  on  simple 
constructs  and  free-form  textual  English.  The  SDL  for  this  project  uti¬ 
lizes  the  Ada  HOL  with  the  exception  of  GOTO.  Following  this  point  in 
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Figure  9  -  Software  System  Methodology  Techniques 


the  design  process,  the  hardware  and  software  functions  are  split 
apart  by  empirical  evaluation  schemes,  and  separate  development 
efforts  proceed  in  parallel.  After  the  completion  of  the  SEDs, 

SDLs ,  and  hardware/software  trade-off  analysis,  it  seems  prudent 
to  exhibit  the  results  by  a  formal  preliminary  design  review. 

Since  the  scope  of  the  contractual  effort  emphasizes  software  system 
re-design,  the  methodology  continues  only  on  the  software  side.  A 
complete  unified  system  design  methodology  could  be  constructed  by 
creating  analogous  hardware  techniques  also  based  on  the  levels  of 
abstraction  techniques.  The  SDL  descriptions  which  have  at  least 
some  part  software  become  bubbles  on  the  data  flow  diagrams  which 
lie  within  the  bounds  of  software  architecture.  If  hardware  is  also 
^resent,  it  is  shown  on  the  DFD  as  boundaries. 

The  first  step  in  the  software  design  phase  is  provided  by  the  tech¬ 
nique  known  as  data  flow  diagrams  (DFD) .  The  data  flow  diagrams  are 
graphical  representations  of  the  software  system.  They  are  used  to 
model  the  system  in  terms  of  input  data,  output  data,  stored  data, 
significant  intermediate  data  forms  and  the  transformation  of  data. 
Like  the  system  entity  diagram,  they  allow  different  users  to  view 
the  system  from  various  levels  of  abstraction,  thereby  allowing  the 
isolation  of  detail  as  required  by  those  users.  The  automation  at 
this  level  allows  for  the  production  of  both  design  and  accompanying 
historical  documentation. 

In  support  of  the  data  flow  diagram  is  the  data  dictionary.  It  is 
here  that  the  data  from  the  DFDs  is  defined  in  terms  of  its  compo¬ 
nent  parts.  Automation  at  this  stage  checks  the  entries  in  the 
dictionary  for  recursive  definitions,  aliases,  and  provides  for  the 
cross-referencing  of  data  items.  This  last  feature  is  very  valuable 
when  those  inevitable  changes  occur,  giving  the  user  a  roster  of 
other  data  items  referenced  by  a  given  data  item  as  well  as  those 
which  make  reference  to  it.  In  this  way,  the  impact  of  a  change 
can  be  evaluated  prior  to  the  actual  change.  Also  logged  into  the 
data  dictionary  are  pseudo  code  descriptions  of  the  data  transfor¬ 
mations  or  processes,  aimed  at  revealing  the  nature  of  the  trans¬ 
formation  that  might  not  be  exposed  by  just  a  name. 
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After  modelling  the  software  system  using  the  data  flow  diagrams, 
the  methodology  advances  to  the  structure  chart  technique,  the 
fifth  step.  Structure  charts  afford  the  user  with  a  graphic 
representation  of  the  system,  but  unlike  the  data  flows,  they 
model  the  system  in  terms  of  modules  or  program  units,  calls  made 
between  them  and  the  data  that  is  passed.  Viewing  the  system  from 
this  vantage  point  is  crucial  since  the  "modules"  suggest  which  Ada 
program  units  will  be  used.  Like  the  data  flows,  structure  charts 
are  strongly  linked  to  the  guiding  principles.  The  designers  will 
utilize  an  automated  tool  to  produce  current  documentation  as  well 
as  historical  documentation.  Structure  charts  provide  the  link 
between  the  data  flow  level  and  the  program  design  language  (PDL) 
or  program  unit  design. 

The  program  design  language  may  be  viewed  as  a  combination  of 
formally  defined  constructs  known  as  keywords  which  are  a  subset 
of  the  Ada  language.  The  purpose  of  the  PDL  is  to  design  the 
module  or  program  unit.  The  result  is  a  design  which  possesses 
accuracy  and  precision  yet  has  allowed  for  a  flexible  range  of 
expressiveness.  As  an  additional  gain,  using  a  subset  of  Ada  for 
the  PDL  will  subtract  from  the  time  it  takes  to  write  the  Ada  code. 
The  PDL  constructs  are  a  subset  of  the  Ada  language,  and  in  turn , 
have  the  SDL  constructs  as  a  subset  (Figure  11) . 

The  concepts  of  structured  design  will  be  utilized  to  guide  in  the 
creation  of  reliable  structures  during  PDL  application.  It  is  at 
this  point  that  two  quantitative  measures  based  on  mathematics  are 
introduced.  These  are  a  logical  complexity  measure  introduced  by 
McCabe  (37)  and  structured  programming  to  two  Italian  mathematicians 
named  Bohm  and  Jacopini  (38) . 

The  importance  of  limiting  a  module's  logical  complexity  within 
some  quantitative  bound  has  recently  gained  recognition  as  a 
heuristic  practice  directly  related  to  reliability.  The  metric 
utilized  in  the  methodology  is  a  derivative  of  a  program's  control 
flow  and  based  on  mathematical  graph  theory.  All  computer  programs 
can  be  expressed  as  graphics  where  each  node  in  the  graph  corre¬ 
sponds  to  a  block  of  code  in  the  program  where  the  flow  is  sequential 


Figure  11  -  SDL/PDL/Ada  Language  Relationship 


and  the  area  corresponds  to  branches  taken  in  the  program.  An  added 
advantage  of  this  complexity  measure  is  that  it  can  be  mathematically 
linked  to  structured  programming. 

Structured  programming  has  its  theoretical  roots  in  a  technical  paper 
by  Bohm  and  Jacopini  who  proved  mathematically  that  any  program  could 
be  constructed  from  three  basic  constructs.  The  importance  of  using 
a  handful  of  constructs  to  create  the  most  complex  of  human  logical 
entities  should  not  be  underestimated.  An  analogy  exists  in  elec¬ 
trical  engineering  where  the  most  complicated  logical  circuit  can  be 
built  by  a  combination  of  "and",  "or",  "not"  gates.  The  lack  of 
basic  constructs  enhances  rather  than  limits  the  programming  process 
by  imposing  a  discipline  at  the  code  level.  All  the  constructs  have 
the  desirable  attribute  of  having  a  single  entry  point,  and  a  single 
exit  point.  This  avoids  code  from  becoming  unwieldly  and  enhances 
comprehendability  and  maintainability.  These  quantitative  measures 
should  enhance  the  Ada  code  which  is  the  final  product. 

Using  the  eight  described  techniques  in  methodical  steps  to  bring 
an  analysis  and  design  project  from  the  requirements  level  to  the 
code  level  is  not  merely  a  show  of  design  technique  agility.  Each 
step  requires  the  performance  of  its  own  validation  function  before 
the  next  step  can  proceed.  This  validation  function  within  a  step 
in  the  project  if  known  as  a  walkthrough  or  design  review. 

When  the  DFDs  are  complete,  a  walkthrough  will  reveal  any  weakness 
in  the  initial  requirements  specification,  and  will  point  up  inter¬ 
face  criteria  and  exception  criteria.  Actual  system  scenarios  may 
be  walked  through  the  DFDs  to  uncover  any  design  omission.  A  design 
may  address  all  the  requirements,  but  validation  will  insure  that 
all  the  requirements  have  been  stated.  The  design  should  not  proceed 
until  the  DFD  milestone  testing  is  complete. 

The  SC  validation  is  again  a  walkthrough,  but  this  time  a  correct 
solution  for  program  units  is  sought  rather  than  a  correct  problem 
definition.  Work  should  not  proceed  until  the  SC  milestone  vali¬ 
dation  is  complete. 


Figure  12  illustrates  the  graphical  and  textual  linkage  for  design 
phases  of  the  methodology. 

Structure  charts  are  followed  by  the  use  of  a  PDL  which  represents 
the  logical  structure  of  each  eventual  module  in  the  system.  The 
PDL  in  this  software  system  design  methodology  is  also  a  subset  of 
the  Ada  language.  Also,  such  attributes  as  coupling,  cohesion,  and 
complexity  should  be  reviewed.  It  is  often  necessary  to  revise  the 
SC  based  upon  the  anticipated  program  unit  not  meeting  modular 
criteria. 

The  last  step  of  the  software  development  is  coding  and  testing. 

Code  should  always  be  accompanied  by  appropriate  walkthroughs. 

Several  studies  done  on  the  usefulness  of  the  walkthroughs  outlined 
above  have  revealed  that  50  to  70  percent  of  all  errors  are  uncovered 
during  the  coding  phase,  and  because  of  this  early  error  detection, 
the  errors  found  after  software  release  were  minor  to  correct.  The 
most  expensive  errors  are  design  errors  and  the  most  common  design 
error  is  that  of  omission  or  some  condition  that  was  overlooked. 
Walkthrough  at  each  step  of  analysis  and  design  should  minimize 
omissions. 

The  following  sections  in  this  designer's  guide  will  fully  describe 
each  of  the  design  methodology  steps  just  outlined. 
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The  System  Entity  Diagram  is  used  to  give  a  graphic  representation 
of  the  hierarchical  organization  of  system  functions  before  hardware/ 
software  trade-offs  are  made.  The  approach  calls  for  the  partitioning 
of  the  system's  functions  into  respective  levels  of  detail.  In  deter¬ 
mining  the  delineation  between  these  levels,  the  employed  technique 
has  utilized  the  concept  of  levels  of  abstraction  popularized  by 
Dijkstra  (22,23).  In  employment  of  this  idea,  the  system  functions 
are  partitioned  into  distinct  "levels"  that  meet  the  design  criteria. 
Each  of  the  levels  forms  a  group  of  related  "entities",  and  is  defined 
in  terms  of  the  preceeding  levels.  The  purpose  of  this  leveling  is " 
to  manage  system  complexity  by  reducing  the  system  to  a  group  of 
smaller  and  more  comprehendable  pieces. 

One  of  the  immediate  advantages  of  this  technique  is  that  it  affords 
an  early  view  of  the  composition  of  the  system  by  the  user.  The  SED 
technique  has  been  specifically  designed  with  the  intention  of  re¬ 
vealing  pertinent  details  without  inundating  the  user  with  the  tech¬ 
nical  mechanics.  The  SED  should  surface  difficulties  so  they  can 
be  easily  identified  and  corrected.  Another  purpose  of  the  SED  is 
to  establish  an  accountability  scheme  for  the  components  when  they 
eventually  find  their  implementation  medium. 

Each  level  depicted  in  the  SED  is  defined  in  terms  of  the  preceeding 
level.  Conceptual  terminology  was  developed  to  label  each  one  of 
the  levels  with  a  unique  title  and  graphical  symbol.  Accordingly, 
the  first  six  levels  have  been  entitled  as  facility,  subfacility, 
component,  subcomponent,  function  and  subfunction.  Each  of  these 
levels  can  be  defined  as  being  a  discrete  grouping  of  or  subdivision 
of  the  system  with  the  distinction  being  the  level  in  which  they 
exist.  It  should  be  noted  that  the  concept  of  levels  is  far  more 
important  than  the  labels  or  symbols  used  for  human  communication 
purposes.  The  symbols  used  to  represent  the  six  levels  are  as 
follows: 

Facility  -  The  highest  level  of  abstraction  is  represented  as: 


Since  the  object  of  the  system  entity  diagram  is  to  represent  the 
system  at  the  highest  levels  of  abstraction  before  any  hardware  or 
software  decision  are  made,  care  must  be  taken  to  maintain  the 
proper  relationships  between  the  levels  and  that  the  designer  is 
not  overwhelmed  by  the  tendency  to  think  in  terms  of  implementation 
details. 

The  graphic  tools  developed  by  Control  Dat*"'Corporation  lend  them¬ 
selves  quite  naturally  to  the  idea  of  the  system  entity  diagram. 

These  automated  techniques  known  as  the  Structured  Analysis, 
Structured  Design/Computer  Aided  Design  of  Software  (SASD/CADS)  tools 
support  the  creation  and  maintenance  of  data  flow  diagrams,  data 
dictionaries  and  structure  charts  in  computer  graphic  form.  The 
concept  of  the  Structured  Analysis  Methodology  inherent  in  the  SASD/ 
CADS  tool  should  enable  designers  to  utilize  the  module  structure 
capability  to  create  and  maintain  the  system  entity  diagram. 

The  system  entity  diagram  (SED)  uses  different  symbols  to  indicate 
different  levels  of  abstraction.  This  reinforces  the  concept  of 
levels  which  is  so  critical  to  the  isolation  of  detail  concept  as 
well  as  enabling  immediate  identification  of  the  level  at  which  the 
system  is  being  illustrated. 

The  use  of  automation  of  the  design  methodology  techniques  should 
free  the  designer  from  manual  drawings,  increase  software  visibility 
by  letting  the  machine  record  all  versions,  and  provide  a  complete 
data  base  for  future  software  engineering  studies  into  productivity. 
The  following  graphics  (Figures  13  thru  15)  represent  automated 
print-outs  of  the  SED  technique  generated  during  the  AN/TSQ-73 
re-design  effort.  They  illustrate  the  decomposition  necessary  to 
architecturally  grasp  the  elements  of  remote  communications  which 
is  one  of  the  four  facilities  of  the  AN/TSQ-73.  For  purposes  of 
illustration,  only  a  small  piece  of  the  actual  TSQ-73  re-design 
SEDs  is  shown  here. 

As  shown  in  Figure  13,  each  of  the  pictured  four  facilities  has  been 
assigned  a  descriptive  title  and  a  corresponding  decimal  number. 


TITLE;  BN/TSQ-73  SEP _ _  ™bb; 

REVISION  3  AUTHOR:  RAIMJAS  DATE;  19'13/81 


Figure  15  -  System  Entity  Diagram  Example 
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The  numbering  system  employed  allows  traceability  among  functions 
at  various  levels  of  detail.  The  relationship  between  the  decimal 
numbers  which  appear  at  different  levels  is  such  that  the  number 
for  any  given  level  is  said  to  have  a  number  which  is  the  root  of 
the  numbers  assigned  on  the  levels  below. 

The  small  arrows  under  each  entity  (Figure  14)  "point"  to  the  page 
or  record  number  which  illustrates  further  decomposition  of  that 
particular  entity.  In  Figure  15,  the  small  arrow  in  the  upper 
left  hand  corner  indicates  the  page  or  record  number  which  illus¬ 
trates  the  level  of  abstraction  directly  above  the  one  shown. 

The  number  of  system  entity  diagrams  generated  for  a  large  system 
can  be  quite  large  and  difficult  to  manage.  The  automated  tool 
provided  by  Control  Data  Corporation  automatically  generates  a 
listing  of  the  titular  (Figures  16-18)  information  contained  in  each 
diagram.  This  feature  supports  ease  of  diagram  recall  and  maintenance 
as  well  as  automatic  generation  and  maintenance  of  a  complete 
historical  data  base  of  all  SED  versions  generated  for  a  particular 
project. 

The  following  guidelines  are  offered  for  system  entity  diagram  users: 

1.  Apply  the  system  entity  diagram  technique  as  a  communication 
tool  to  represent  the  hierarchical  organization  of  system  func¬ 
tion  independent  of  implementation  media. 

2.  Search  the  specification  document  to  identify  high  level 
groupings  of  functional  areas.  The  labels  for  these  groups 
should  appear  as  titles  for  the  first  level  entities 
(facilities) . 

3.  Decompose  the  system  into  functional  components  in  an 
iterative  fashion. 

4.  Continue  the  decomposition  until  a  level  of  detail  is  revealed 
which  will  allow  any  given  entity  or  functional  area  to  be 
assigned  to  a  hardware,  software  or  manual  implementation 
medium. 
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Use  the  system  entity  diagram  in  concert  with  the  Ada-based 
textual  system  design  language  (see  section  immediately 
following)  to  identify  and  correct  deficiencies  in  the  system 
design  until  a  satisfactory  result  is  obtained. 
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SYSTEM  DESIGN  LANGUAGE 

The  purpose  of  the  System  Design  Language  technique  is  to  provide 
an  Ada-based  textual  representation  of  system  functions.  In  order 
to  meet  this  objective  the  System  Design  Language  (SDL)  technique 
must  represent  the  following  features  of  the  system  in  question: 

•  System  Objective (s) 

•  System  Requirements  and  Capabilities 

•  System  Capacities 

•  System  Constraints 

•  System  Entities,  Subentities,  and  their  relationships 

•  System  Control 

•  System  Data  Flow 

•  System  Exception  Handling 

In  the  process  of  including  the  above  features  in  the  SDL  it  is 
important  to  keep  in  mind  that  the  combined  purpose  of  these  two 
steps  (SED  &  SDL)  is  ultimately  to  specify  the  functions  of  the 
system  at  a  level  where  the  systems  engineer  may  separate  hardware 
functions  from  software  functions.  Thus,  the  system  design  lan¬ 
guage  maps  the  information  presented  graphically  by  the  SED  eech- 
nique  into  more  detailed  language-oriented  text  to  describe  system 
processes  and  provide  information  for  hardware/ software  eval¬ 
uations. 

The  following  principles  were  selected  as  guiding  criteria  in 
choosing  the  mechanisms  of  the  system  design  language.  The  in¬ 
clude: 

1)  Clarity  -  The  SDL  must  be  able  to  clearly  apply  all  concepts 
and  constraints  that  the  chosen  design  allows. 

2)  Conciseness  -  The  SDL  should  be  concise  allowing  designers 
and  reviewers  to  obtain  a  maximum  amount  of  information  in  a 
minimum  amount  of  time.  This  usually  implies  that  the  fewer 
ways  to  say  the  same  thing  the  better,  and  suggests  special 
cases  are  to  be  avoided. 

3)  Lack  of  Ambiguity  -  The  meaning  of  any  SDL  statement  or  con¬ 
struct  must  be  clear  and  unambiguous.  Any  SDL  construct  or 
statement  should  have  only  a  single  interpretation. 
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4)  Completeness  -  It  is  improtant  to  be  able  to  express  any  con¬ 
cept  or  constraint  the  system  requires.  Any  aid  the  SDL  gives 
in  ensuring  all  cases  are  covered  is  a  plus. 

5)  Logic  -  The  SDL  should  be  capable  of  describing  problems  in¬ 
dependent  of  solutions  and  solutions  independent  of  low- 
level  details  like  hardware  without  masking  the  requirements 
on  the  lower  levels. 

6)  Ability  to  Express  Relationships  -  The  SDL  should  allow  one 
to  easily  relate  various  levels  of  problem  description  and 
solution  to  higher  and  lower  levels,  ultimately  including  the 
code. 

7)  Ease  of  Modification  -  The  SDL  must  allow  easy  modification  of 
designs  both  during  the  design  process  as  problems  are  un¬ 
covered  and  in  development  as  changes  are  required. 

Since  the  System  Design  Language  is  Ada-based,  the  use  of  Ada 
program  units  will  be  employed  to  accurately  describe  the  structure 
of  the  system.  To  this  end,  the  following  guidelines  in  the  use 
of  the  Ada  program  units  at  the  system  level  are  offered: 

•  Utilize  packages  to  represent  collections  of  logically 
related  system  activities.  The  items  identified  in  any 
given  package  should  be  logically  independent  from  those 
represented  in  other  packages. 

•  Utilize  procedures  and  functions  to  represent  system 
activities  which  appear  to  be  sufficiently  distinct  to  act 
as  stand-alone  units  but  at  the  same  time,  dependent  upon 
other  stand-alone  units  to  accomplish  a  more  global 
activity. 

•  Utilize  tasks  to  represent  activities  which  can  provide 
services  to  other  program  units  in  a  concurrent  fashion. 

Based  on  these  guidelines,  it  appears  that  the  overall  structure 
of  the  SDL  should  take  advantage  of  Ada's  "packaging"  feature  with 
the  titles  and  numbers  of  the  packages  being  identical  to  those 
found  on  the  first  level  of  the  SED. 


An  example  of  the  use  of  Ada's  packaging  feature  applied  to  the  SED 
shown  in  Figure  13  would  result  in  a  primitive  SDL  with  the  following 
structure . 

procedure  TSQ-73  is 

••• 

package  COMMAND  AND  CONTROL  (1.0)  is 

••• 

end  COMMAND  AND  CONTROL; 

package  TARGET  CONTROL  (2.0)  is 

••• 

end  TARGET  CONTROL; 

package  REMOTE  COMMUNICTION  (3.0)  is 

••• 

end  REMOTE  COMMUNICTION; 

package  RADAR  COMMUNICTION  (4.0)  is 

••• 

end  RADAR  COMMUNICATION; 
end  TSQ-73; 

The  package  concept  as  used  in  the  above  example  shows  that  four 
highly  independent  system  activities  have  been  identified.  This 
is  accomplished  by  searching  the  specification  document  to  identify 
high-level  groupings  of  functional  areas.  If  at  this  point  the 
designer  feels  that  the  functional  areas  which  have  been  iden¬ 
tified  are  not  independent/  other  groupings  should  be  investigated 
to  achieve  the  highest  degree  of  independence  possible.  When  this 
result  is  achieved,  the  designer  has  used  Ada  program  units  (in 
this  case  packages)  to  describe  the  relationship  among  the  highest 
level  entities  in  the  system. 

In  this  form  the  SDL  does  not  add  any  new  information  to  that 
shown  in  graphical  form  in  Figure  13.  To  overcome  this  limitation, 
Ada's  comment  feature  will  be  employed.  Comments  will  provide  a 
description  of  each  high  level  program  unit  which  has  been  identified 
for  system  functions.  The  description  should  include  the  system 
requirements,  capabilities,  capacities,  and  constraints  that  are 
addressed  by  that  particular  program  unit. 
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To  illustrate  the  use  of  the  comment  feature  a  small  portion  of 
the  comments  for  the  remote  communication  package  are  given  below. 

package  REMOTE  COMMUNICATION  (3.0)  is 

—  The  objective  of  the  REMOTE  COMMUNICTION  SYSTEM  (3.0)  is 
— to  enable  the  TSQ-73  to  communicate  digitally  with  various 
— remote  sites  by  means  of  the  previously  defined  military 
— protocols,  TADIL-B,  ATDL-1,  and  modified  MBDL.  The  remote 
— communication  subsystem  shall  provide  for: 

—  -2  group  data  links  (ATDL-1) 

-2  battalion  data  links  (ATDL-1) 

—  -2  remote  radar  data  links  (ATDL-1) 

-1  tactical  operations  system  data  link  (ATDL-1) 

—  -1  air  traffic  management  system  data  link  (ATDL-1) 

-1  inter-service  communication  data  link  (ATDL-1) 

-4  fire  unit  data  links  (MBDL) 

end  REMOTE  COMMUNICATION; 

Comments  appropriate  to  the  functional  nature  of  the  other  packages 
which  have  been  identified  would  also  be  provided  at  this  time. 

It  is  important  to  reemphasize  that  the  principles  of  the  SED  and 
SDL  techniques  are  communicative  in  nature.  Thus,  the  information 
presented  at  each  level  of  each  technique  must  be  consistent  and 
state  precisely  what  the  design  requires. 

The  SDL  generation  proceeds  to  the  next  level  of  abstraction.  At 
this  level  the  functionality  required  to  satisfy  the  objectives  of 
each  package  are  detailed  as  shown  in  Figure  14.  For  example,  the 
functional  areas  identified  for  the  Remote  Communication  (3.0) 
package  are  Communication  Supervisor  (3.1),  Intra  System  Transfers 
(3.2),  and  Communication  Protocols  (3.3). 

package  REMOTE  COMMUNICATION  (3.0)  is 

—  The  Objective  of  the  REMOTE  COMMUNICATION  SUBSYSTEM  (3.0)  i 
— to  enable  the  TSQ-73  to  communicate  digitally  with  various 
— remote  sites  by  means  of  the  previously  defined  military 


— protocols,  TADIL-B,  ATDL-1,  and  modified  MBDL.  The  remote 

— communication  subsystem  shall  provide  for: 

-2  group  data  links  (ATDL-1) 

-2  battalion  data  links  (ATDL-1) 

-2  remote  radar  data  links  (ATDL-1) 

-1  tactical  operations  system  data  link  (ATDL-1) 

-1  air  traffic  management  system  data  link  (ATDL-1) 

-1  inter- service  communication  data  link  (ATDL-1) 

-4  fire  unit  data  links  (MBDL) 

package  COMMUNICATION  SUPERVISOR  (3.0)  is 

—  The  objectives  of  the  Communication  Supervisor  (3.1)  are: 

— 1.  To  provide  a  controlling  interface  between  the  command 

and  control  1.0  package  [which  in  turn  handles  communication 
between  Target  Control  (2.0)  and  radar  communcation  (4.0)] 
and  the  remote  communication  package. 

— 2.  To  provide  for  the  management  of  the  remote  communication 
package . 

end; 

package  INTRASYSTEM  TRANSFERS  (3.2)  is 

end; 

package  COMMUNICATION  PROTOCOLS  (3.3)  is 


end; 

end  REMOTE  COMMUNICATION  (3.0); 

To  complete  the  example  of  the  specification  portion  for  the  commu¬ 
nication  supervisor  package  the  items  identified  in  the  third  level 
of  abstraction  are  included  [See  Figure  (15)  for  the  corresponding 
SED]  . 
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package  COMMUNICATION  SUPERVISOR  (3.1)  is 

--  The  objectives  of  the  COMMUNICATION  SUPERVISOR  (3.1)  are: 

— 1.  To  provide  a  controlling  interface  between  the  command 
and  control  1.0  package  [which  in  turn  handles  commu¬ 
nication  between  TARGET  CONTROL  (2.0)  and  radar  commu¬ 
nication  (4.0)]  and  the  remote  communication  package. 

— 2.  To  provide  for  the  management  of  the  remote  communication 
package . 

procedure  Consume  Internal  Message  (3.1.1); 
procedure  Initialize  Remote  Communication  (3.1.2); 
procedure  Manage  Data  Links  (3.1.3); 
procedure  Manage  Messages  (3.1.4); 

procedure  Manage  Fault  Detection,  Correction  &  Reporting 
(3.1.5) ; 

procedure  Terminate  Remote  Communication  (3.1.6) ; 
procedure  Produce  Internal  Message  (3.1.7); 

end; 

Based  on  the  guidelines  presented  previously,  the  procedures  id¬ 
entified  in  the  communication  supervisor  package  are  sufficiently 
distinct  to  be  stand-alone  units  but  are  dependent  upon  the  other 
procedures  in  that  package  to  satisfy  the  objective  of  the  more 
global  communication  supervisor  functional  area.  In  contrast, 
the  communication  supervisor  is  independent  of  the  intrasystem 
transfers  and  communication  protocol  activities  (hence  utilization 
of  the  package  constructs)  while  all  three  are  needed  to  satisfy 
the  Remote  Communication  objective.  The  Remote  Communication 
package  is  also  independent  of  Command  and  Control,  Target  Control 
and  Radar  Communication,  the  combination  of  which  meet  the  mission 
of  the  A/N  (TSQ-73) . 

If  more  information  is  required  to  detail  the  design  concepts,  the 
option  of  providing  the  package  body  is  available.  The  package 
body  provides  the  logic  required  to  describe  (not  implement)  the 
procedures  identified  in  the  specification  portion  as  well  as 
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other  local  procedures,  functions,  or  tasks  as  necessary  to  meet 
the  requirements  of  those  procedures. 

An  example  of  this  guideline  is  shown  below  using  the  portion  of 
the  package  body  for  communication  supervisor  which  pertains  to 
the  procedure  CONSUME  INTERNAL  MESSAGE  (3.1.1)  follows. 

procedure  CONSUME  INTERNAL  MESSAGE  (3.1.1)  is 
begin 

if  Command  and  Control  Message  or  Communication 
Protocol  Message  =  then 
case  Message  Type  is 

when  Initialize  Remote  Communication  => 

Queue  Message  to  Initialize  Remote 
Communication  (3.1.2) ; 
when  Manage  Data  Links  => 

Queue  Message  to  Manage  Data  Links  (3.1.3); 
when  Manage  Messages  => 

Queue  Message  to  Manage  Messages  (3.1.4); 
when  Others  => 

set  error  code  for  invalid  message  type; 
queue  to  produce  Internal  Message  (3.1.7); 
end  case; 

else 

set  error  code  for  invalid  message  originator; 
queue  to  produce  Internal  Message  (3.1.7); 
end  if; 

end  CONSUME  INTERNAL  MESSAGE; 

The  previous  example  illustrates  the  structural  features  of  the 
SDL  and,  in  addition  shows  that  system  control,  system  data  flow, 
and  system  exception  handling  can  be  illustrated  as  well. 

Further  description  of  more  specific  items  found  at  lower  levels  of 
abstraction  can  be  described  using  the  strong  typing  features  of  Ada. 
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The  example  shown  in  Figures  19  and  20  represent  how  system  re¬ 
quirements,  capabilities,  capacities,  and  constraints  can  be  des¬ 
cribed  in  the  SDL  using  these  strong  typing  features.  A  package 
of  system  level  data  types  can  serve  as  a  collection  mechanism 
for  these  items. 

To  aid  in  the  use  of  the  SDL  described  here  the  following  guide¬ 
lines  are  offered. 

1.  Utilize  all  features  of  the  Ada  language  as  necessary  to  pro¬ 
vide  the  required  system  descriptions,  while  maintaining  a 
structured  approach.  Avoid  the  use  of  the  GO  TO  construct. 

2.  Use  the  Ada  program  units  according  to  the  following  criteria: 

•  Utilize  packages  to  represent  collections  of  loqically 
related  system  activities.  The  items  identified  in  any 
given  package  should  be  logically  independent  from  those 
represented  in  other  packages. 

•  Utilize  procedures  and  functions  to  represent  system 
activities  which  appear  to  be  sufficiently  distinct  to 

act  as  stand-alone  units  but  at  the  same  time,  dependent  upon 
other  stand-alone  units  to  accomplish  a  more  global  activity. 

•  Utilize  tasks  to  represent  activities  which  can  provide 
services  to  other  program  units  in  a  concurrent  fashion. 

3.  Proceed  to  a  level  of  detail  which  allows  hardware/ software 
trade-offs  to  be  made. 

4.  Provide  appropriate  comments  for  each  high  level  program  unit. 

5.  Generate  the  SDL  simultaneously  with  the  SED  using  each  tech¬ 
nique  to  check  the  other. 

6.  Maintain  consistency  with  numbering  conventions. 

7.  Keep  in  mind  that  the  SDL  is  a  communicative  device,  the  pur¬ 
pose  of  which  is  to  describe  system  functionality. 

8.  Do  not  attempt  to  write  executable  source  code. 
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— Support  will  be  maintained  for  13  active  data  links 
— plus  an  on-line  redundant  data  transmission  link 
— for  each  active  link.  Thus,  a  total  of  26  active 
— links  with  a  minimum  of  two  spare  links  will  be  re- 
— quired.  Each  link  will  be  capable  of  utilizing  baud 
— rates  of  600  or  1200  bps,  and  will  support  the  pre- 
— defined  TADIL-B,  ATDL-1,  and  MBDL  military  protocols. 

type  PROTOCOL  CHOICE  is  (TADIL-B,  ATDL-1,  MBDL); 

BAUD  RATE  CHOICE : constant  array  (PROTOCOL  CHOICE)  of 
integer  :  =  (1200,  1200,  600); 
type  ORIENTATION  CHOICE  is  (BIT  ORIENT,  CHAR  ORIENT) ; 
type  TRANSMISSION  CHOICE  is  (PT  TO  PT,  MULTI  DROP); 
type  SYNCH  CHOICE  is  (SYNCHRONOUS,  ASYNCHRONOUS); 
type  MODE  CHOICE  is  (PRIMARY,  REDUNDANT) ; 

type  PRI  MBDL  LINK  SPEC  is 
record 

PROTOCOL  :  PROTOCOL  CHOICE  :=  MBDL; 

BAUD  RATE  :  INTEGER  BAUD  RATE  CHOICE 
(PROTOCOL) ; 

ORIENTATION  :  ORIENTATION  CHOICE  :=  CHAR  ORIENT; 
TRANSMISSION  :  TRANSMISSION  CHOICE  PT  TO  PT; 
SYNCH  :  SYNCH  CHOICE  :=  SYNCHRONOUS; 

MODE  :  MODE  CHOICE  :=  PRIMARY; 
end  record; 
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type  RED  MBDL  LINK  SPEC  Is 


record 

PROTOCOL  :  PROTOCOL  CHOICE  :=  MBDL; 

BAUD  RATE  ;  INTEGER  :=  BAUD  RATE  CHOICE 
(PROTOCOL) ; 

ORIENTATION  :  ORIENTATION  CHOICE  :=  CHAR  ORIENT 
TRANSMISSION  :  TRANSMISSION  CHOICE  :  =  PT  TO  PT; 
SYNCH  :  SYNCH  CHOICE  :=  SYNCHRONOUS; 

MODE  :  MODE  CHOICE  :=  REDUNDANT; 
end  record; 


PRIMARY  MBDL  LINK  s  PRI  MBDL  LINK  SPEC  range  1 ...  4 ; 
REDUNDANT  MBDL  LINK  :  RED  MBDL  LINK  SPEC  range  1 ...  4 ; 


Figure  20 


DATA  FLOW  DIAGRAM  (DFD) 


In  order  to  obtain  a  more  distinct  picture  of  the  system's  func¬ 
tions  and  logical  flow  of  data,  a  graphical  abstraction  system 
flowchart  known  as  a  data  flow  diagram  is  utilized  (39,40,41,42). 
Data  flow  diagrams  attempt  to  display  compact  generalized  pictures 
of  functional  requirements  and  their  accompanying  data  transforma¬ 
tions.  This  technique,  also  known  as  a  "bubble  chart",  models  the 
system  in  terms  of  the  following: 

•  Input  Data 

•  Output  Data 

•  Stored  Data 

•  Significant  Intermediate  Data  Forms 

•  Data  Transformations 

Although  DFDs  generally  occur  on  many  conceptual  levels,  the 
initial  level  attempts  to  show  on  one  page  the  major  processes 
required  in  the  system  and  is  known  as  the  context  diagram.  Con¬ 
sequently,  only  those  details  which  are  relevent  to  DFDs  should 
be  present  at  this  level  of  abstraction.  The  emphasis  should 
be  to  identify  and  isolate  major  functions  and  resultant  data 
transformations.  Each  transformation  may  eventually  become  one 
or  more  modules  at  a  lower  level,  but  the  DFD  should  not  provide 
details  of  procedural  processes  or  of  implementation. 

Certain  basic  graphic  symbols  are  used  to  identify  components  of 
the  DFD.  These  are  described  as  follows: 

The  Source  or  Sink  is  the  interface  to  the  external  world  through 
which  data  enters  or  leaves  the  system.  This  is  required  by  a 
labeled  rectangle.  Example: 


NAME 


The  Data  Flow  identifies  information  moving  from  one  part 
of  the  system  to  another.  It  should  not  "pass  through" 
intermediate  processes.  The  data  flow  acts  in  a  manner 
similar  to  a  queue  in  that  information  first  in  is  first 
out.  Care  should  be  taken  to  choose  descriptive  data 
flow  names.  The  data  flow  is  represented  by  a  labeled 
straight  line  with  an  arrowhead  on  at  least  one  end 
which  indicates  the  direction  of  the  flow.  Example: 

:jame 

- ► 

A  File  is  a  place  where  data  resides  for  possible  future 
use. 

A  file  is  shown  as  a  labeled  line  connected  by  a  perpen¬ 
dicular  arrow.  Example: 


FILE 


A  Transformation  is  the  most  basic  symbol  of  the  data  flow 
diagram.  It  identifies  a  function  that  transforms  data. 

It  can  represent  changes  in  any  of  the  following: 

•  Value 

•  Format 

•  Meaning 

•  Residence 

Transformations  are  stated  in  terms  of  simple  sentences 
indicating  input  and  output.  The  basic  form  is  an  impera¬ 
tive  sentence  consisting  of  a  "meaningful"  verb  and  a  direct 
object.  It  is  graphically  represented  by  a  circle  with 
arrows  indicating  input  and  output.  Example: 


As  mentioned  earlier,  data  flow  diagrams  can  have  different 
levels  of  abstraction.  Thus,  data  flow  diagrams  can  be 
expanded  by  choosing  one  transformation  and  developing  an¬ 
other  diagram  using  the  same  process. 

In  summary,  the  following  guidelines  are  to  be  used  when 
creating  DFDs  and  representing  different  levels  of  abstrac¬ 
tion: 

1.  Utilize  simple  sentences  in  transformation  bubble. 

2.  Number  transformation  bubble  reflecting  logical  level. 

3.  Capture  all  types  of  input  and  output  from  transformation 
bubble . 

4.  Avoid  detailed  control  logic  representation. 

5.  Choose  data  flow  names  that  are  descriptive. 

6.  Attempt  to  limit  diagrams  to  seven  transformations. 

7.  Seek  a  balanced  workload  for  transformations. 

8.  Break  transformations  down  to  simplest  components  by 
additional  levels. 

9.  Illustrate  boundaries  of  the  system  when  applicable. 

An  illustrative  data  flow  diagram  is  shown  in  Figures  21- 
29  and  is  an  extension  of  the  remote  communications  example 
begun  at  the  SED  and  SDL  level. 
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Figure  23  -  Data  Flow  Diagram  Example 
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Figure  24  -  Data  Flow  Diagram  Example 


B-59 


TITLE:  3. 3. 3. 3  XtllT  MESSAGE  DFD 


PAGE:  30-1 


REVISION  G 


AUTHOR:  LUD-'RAU/GIC 


DATE:  2^5/82 


ROOT:  3.0 


CONSUME 

conn.supv 
nsc_  ■ 

3.3.3~.  1 


XtllT  PROMPT 


J  \ 

f  ENCODE  \ 

msg  "  L 

‘3. 3.3.3. 1/ 


REMOTE 
MBDL  SITES 


\  MBDL  MSG 

\blocr  ' 

\ 


ENCODED  MSG 


— WSEND_MSG_ 
Y3.3.3.3.2 


PRODUCE 

C0MM.SUP9. 

J1SG_ 

3. 3. 3. 7 


^MIT  STATUS 


b-60 


TITLE:  3. 3. 3. 3. 2  SEND  MESSAGE  DFD 


REVISION  0 


NOTES: 


AUTHOR:  LUD/RA14/GIC 


PAGE:  305 


DATE:  2/5/82 


ROOT:  3.9 


DATA  LINE 
TABLE 


ENCODE 

HSG_ 

3. 3. 3. 3. 1 


ED  LINE 
m  i 


PRI  LINE 
ADDR 


PRI  LINE 
ADDR 


REOOTE 

NBDL.SITES 


RED  MBDL 
riSG*"BLOCR , 


'PRI  MBDL 
nSG“BLOCR 


ENCODED 

MSG 


f SELECT  N 
I  NSG  FOR" 

\  XrflT 
3.3.3.2"2< 


HIGHEST_PRI^>/IN^ROT\ 

ENCODED  J1SG  J‘=k  3.3. 3. 2.) 

V  2  J 


/HIGHEST 
\  /  PRI 

\  j  ENCODEDJ1SG 

i _ L _ 


RED  LINE 
ADDR 


XMIT  STATUS' 


ENCODED  !1SG_ 


PRODUCE 
conn. sup v 


B-61 
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Figure  27  -  Data  Flow  Diagram  Example 


B-62 
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Figure  28  -  Data  Flow  Diagram  Example 
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DATA  DICTIONARY 


In  utilizing  data  flow  diagrams  and  subsequently,  structure  charts 
as  software  design  techniques,  the  system  designer  generates  a  vast 
number  of  terms  associated  with  data  or  processes.  Some  words  by 
their  nature  are  ambiguous  while  others  are  esoteric.  The  use  of 
acronyms  or  aliases  does  little  to  reveal  complete  understanding 
of  a  data  flow,  yet  is  commonplace  at  this  design  staqe.  It  is,  there 
fore,  essential  to  have  documentation  that  addresses  the  problems 
arising  when  multiple  interpretations  are  given  to  a  single  term 
and  to  add  awareness  of  how  apparently  minor  changes  can  impact  the 
system. 

The  data  dictionary  is  a  design  technique  which  helps  to  meet  these 
objectives.  Used  in  parallel  with  data  flow  diagrams  and  updated 
as  required  when  structure  charts  are  created,  the  data  dictionary 
serves  as  a  central  repository  for  data  definitions  and  process 
descriptions.  All  data  flows,  files  and  transformations  from  the 
data  flow  diagrams  will  be  defined  in  the  dictionary,  thus  ensuring 
a  complete  glossary  of  data  items  and  transformation  descriptions. 
Data  items  on  the  structure  chart  will  also  appear  in  the  dictionary 
if  different  from  data  on  the  flow  diagrams. 

The  automated  data  dictionary  tool  developed  by  Control  Data  will  be 
utilized  for  this  application.  Entries  are  made  in  a  prescribed 
format.  The  automated  tool  eliminates  the  drudgery  involved  in 
finding  aliases,  cross-referencing  modules  impacted  by  changes  in 
data  items  and  locating  recursive  definitions.  In  particular, 
the  cross-referencing  capability  helps  to  ease  the  ripple-effect 
of  changes  made  at  a  later  date.  Below  are  the  formats  of  the 
entries  and  some  general  guidelines  for  creating  the  dictionary. 

Entries  can  be  of  two  types:  Data  Definitions  and  Action  Definitions 
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DATA  DEFINITIONS'  FORMAT 


DATA  HEADER: 

— DATA  ATTRIBUTES; 
DATA  COMPOSITION; 


The  DATA  HEADER  contains  the  name  and  type.  The  type  may  be 
either  FLOW,  FILE,  or  (all  others)  ELEMENT. 


The  DATA  ATTRIBUTES  are  comments  written  in  English  to  explain 
the  usage  or  to  clarify  an  item.  They  are  optional. 


The  DATA  COMPOSITION  contains  COMPONENTS  and  META-SYMBOLS. 
COMPONENTS  are  FLOW,  ELEMENTS  or  FILES. 


The  META-SYMBOLS  are:  CONJUNCTION  & 

ALTERNATION  | 

ITERATION  {  } 

OPTIONAL  [  J 


(and) 

(or) 

(repeat) 


Example : 

OPERATOR_MESSAGE  (FLOW) :  HEADER 

-THESE  MESSAGES  ARE  MANUALLY  GENERATED  BY  THE  OPERATOR (S)  ATTRIBUTE 
{ COMMAND | REQUEST } I  COMPOSITION 

OPERATOR_MESSAGE  here  is  defined  to  be  a  series  of  commands  or 
requests.  The  exclamation  point  indicates  the  end  of  the  defini¬ 
tion.  The  terms  COMMAND  and  REQUEST  would  also  be  entries  in 
the  data  dictionary.  All  FLOW  and  FILE  types  would  eventually  be 
defined  in  terms  of  ELEMENT  types.  ELEMENT  types  should  be  reduced 
to  self-defining  ELEMENT  types  and  then  should  be  elaborated  on 
with  the  attribute  or  comment  section  of  the  definition.  In  this 
way  an  individual  unfamiliar  with  the  definition  of  a  term  can 
trace  its  meaning  through  successive  levels  to  its  exact  compo¬ 
sition  if  necessary. 
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Some  data  definitions'  guidelines  follow: 

•  Words  are  ambiguous,  select  the  best  one  that  can  be  found  and 
define  it  precisely. 

•  Avoid  circular  definitions. 

•  Reduce  everything  to  self  defining  terms. 

•  Define  self  defining  terms  with  comments. 

•  Entries  are  defined  in  terms  of  composition;  to  show  usage 
use  comments. 

•  Upon  completion,  walkthrough. 

ACTION  DEFINITIONS'  FORMAT _ 

ACTION  HEADER: 

— ACTION  ATTRIBUTES; 

ACTION  FLOW: _ ( 

The  ACTION  HEADER  contains  name  and  type  and  number  corresponding 
to  the  "bubble"  (the  type  is  process) . 

—  A  transformation  is  a  process  on  the  DFD  level. 

—  A  procedure  is  an  example  of  a  module  on  SC  level. 

The  ACTION  ATTRIBUTES  are  comments  and  are  used  like  the  DATA 
ATTRIBUTES . 

The  ACTION  FLOW  contains  flow  descriptions  and  comments  written 
in  a  pseudo  code. 

Example: 

VAL IDATE_ME S SAGE  is  a  bubble  from  a  data  flow  diagram  and  is 
enumerated  as  3.1. 

VAL I D ATE_ME S SAGE  (PROCESS  3.1) 

IF  MESSAGE  IS  MBDL 
THEN 

PERFORM  PARITY-CHECK 
ELSE 


PERFORM  CHECKSUM; 


UPDATE  TABLE; 

END  IF; 

IF  MESSAGE_COUNT  IS  >N  THEN 
—  N  IS  NUMBER  OF  ACCEPTABLE  FAILURES 
SEND_ALERT; 

END  IF; ! 

Some  action  flow  guidelines: 

•  Use  nouns  from  data  dictionary. 

•  Use  specific  descriptive  verbs  (not  do,  process,  handle) . 

•  Avoid  adjectives  and  adverbs. 

•  Tell  policy  not  procedure. 

•  Refer  to  input  and  output. 

•  Remember  rejects. 

In  summary,  the  data  dictionary  helps  to  achieve  the 
following  objectives: 

1.  Establish  a  glossary  of  terms. 

2.  Provide  standard  terminology. 

3.  Define  all  data  on  data  flow  diagrams. 

4.  Define  all  transformations  on  data  flow  diagrams. 

5.  Provide  the  capability  for  cross-referencing. 

6.  Resolve  the  problems  of  aliases  and  acronyms. 

7.  Help  reduce  maintenance  costs. 

The  Data  flow  diagram  and  associated  data  dictionary  entries 
shown  in  Figures  30  thru  34  serve  to  illustrate  the  data 
dictionary  tools  (flow,  process,  file  descriptions,  cross- 
referencing  and  cross-checking)  as  they  apply  to  the  qiven  data 
flow. 
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MBDL-MSG-BLOCN  (FLOW)J 

•FORMAT  FOR  MBDL  BLOCK* 

*  -CHARACTERS*  -MESSAGE  LENGTH  =  128*  (SYNC.  4 
SYNC_  4 
S-O-H  & 

BEST  I NAT  I ON_S TAT  ION-ID  4 
DESTINATION- PERIPHERAL-ID  4 

ORIGINATION-STATION-ID  ORIGINATION-PERIPHERAL-ID  4 
ORIGINATION-TIME  4 
TRANSMISSION-TIME  4 

MESSAGE-SECURITY  MESSAGE-PRIORITY  4 

MESSAGE-TYPE  4 

ORIGINATOR-SERIAL-NUMBER  4 

S-T-X  4 

TEXT-LENGTH  4 

TRANSACTION-COMMAND  4 

TARGET-IDENTITY  4 

HEIGHT-DATA  4 

X-COORDINATE.DATA  4 

Y-COORDINATE-DATA  4 

ALERT-STATUS  4 

E_T_X  4 

CHECK-SUM  4 

F_F  4 

E-O-T  4 

RED-LINE-ADDR  4 
PRI-LINE.ADDR) ! 


MESSAGE-PRIORITY  (ELEMENT) 5 

-  CHARACTER  POSITION  =  19* 

-  INTEGER* 

•INDICATES  PRIORITY  OF  MESSAGE  IN 
ENCODED-MESSAGE. BUFFER* 

*  (II 
21 
31 
4  I 
51 
61 
71 
8  I 

9)  *  ! 


Figure  30  -  Data  Dictionary  Example  (Flow) 


3.1  LINE- PROTOCOL-MANAGER  (PROCESS  3 . 3 . 3 . 3 . 2 . 2  )  J 

GET  PRI_LINE_ADDR » 

GET  RED-LINE.ADDR? 

GET  HIGHEST-PRIORITY-ENCODED-MSG? 

PUT  MSG  BLOCK  TO  DESTINATION  ON  PRIMARY  LINE? 
PUT  MSG  BLOCK  TO  DESTINATION  ON  REDUNDANT  LINE? 
POST  XMI T-STATUS ! 


3.2  SELECT-MESSAGE-FOR-XMIT  (PROCESS  3 .3 .3 .3.2  ♦  1 > t 

-  MESSAGE  COUNT  IN  BUFFER  (O..N>? 

IF  MESSAGE  COUNT  IN  BUFFER  =/  0  THEN! 

FOR  EACH  MESSAGE  LOOP4. 

DETERMINE  PRIORITY? 

STORE  PRIORITY. 

END  LOOP. 

else: 

DO  NOTHING. . 

END  IF? 

RETURN  MESSAGE  WITH  HIGHEST  PRIORITY?! 

EOI  ENCOUNTERED. 


Figure  31  -  Data  Dictionary  Example 


(Process) 
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ACK.O  (ELEMENT) 


(ASCII  ACK  l 

0)i  ’PRIMARY  LINE  ACKNOWLEDGEMENT’! 


ACK_ 1  (ELEMENT): 

(ASCII  ACK  & 

l)f  ’REDUNDANT  LINE  ACKNOWLEDGEMENT’! 


ALERT-STATUS  (ELEMENT) : 

-  CHARACTER  POSITION  =  46; 

-  INTEGER) 

(DIGIT)! 


BAUD-RATE  (ELEMENT): 

■C300I 
600  I 
7501 
12001 
24001 
4800} ! 


CHECK-SUM  (ELEMENT) J 

-  CHARACTER  POSITION  =  (48+N); 

-  integer; 

(DIGIT) ! 


DATA-LINE-TABLE  (FILE): 

DESTINATIQN-STATION-ID  l 
(PROTOCOL-ASSIGNMENT  & 
BAUD-RATE  % 

PR I _L I NE.ADDR  & 
RED_LINE_ADDR) ! 


DESTINATION-PERIPHERAL-ID  (ELEMENT).’ 

-  CHARACTER  POSITION  =  (6. .7); 

-  integer; 

(DIGIT  S 
DIGIT) * 

Figure  32  -  Data  Dictionary  Example  (File  Description) 
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MBDL-MSG-BLOCK  (FLOW) 


""  Makes  Refererices  To  "" 

ALERT-STATUS  .  (ELEMENT) 

CHECK-SUM  .  (ELEMENT) 

DESTINATION- F'ERIF’HERAL-ID  .  .  .  (ELEMENT) 

DESTINATION_STATION_ID  ....  (ELEMENT) 

E-O-T . . . (ELEMENT) 

E-T.X . . . (ELEMENT) 

F_F . (ELEMENT) 

HEIGHT-DATA  .  ...  (ELEMENT) 

MESSAGE-PRIORITY  .  (ELEMENT) 

MESSAGE-SECURITY  .  (ELEMENT) 

MESSAGE-TYPE  .  (ELEMENT) 

ORIGINATION-PERIPHERAL-ID  .  .  .  (ELEMENT) 

ORIGINATION_STATION_ID  ....  (ELEMENT) 

ORIGINATION-TIME  .  (ELEMENT) 

ORIGINATOR-SERIAL-NUMBER  .  .  .  (ELEMENT) 

FRI_LINE_ADDR  .  (ELEMENT) 

RED-L I NE-ADDR  .  (ELEMENT) 

SYNC- . .  (ELEMENT) 

S-O-H . (ELEMENT) 

S_T_X . (ELEMENT) 

TARGET-IDENTITY  .  (ELEMENT) 

TEXT-LENGTH  .  (ELEMENT) 

TRANSACTION-COMMAND  .  (ELEMENT) 

TRANSMISSION-TIME  .  (ELEMENT) 

X-COORDINATE-DATA  .  (ELEMENT) 


""  Is  Referenced  By  "" 
HIGHEST.PRIORITY-ENCODED-MSG  .  (FLOW) 

PRI-MBDL-MSG-BLOCK  .  (FLOW) 

RED_MBDL_MSG_BLOCK  .  (FLOW) 


Figure  33  -  Data  Dictionary  Example  (Cross  Reference) 


At  At 


Undefined  Names 


At  At 


NO  UNDEFINED  ENTRIES  FOUND 
CROSS  CHECK  REPORT  FOR  DD  ‘DRAFT* 

""  Entries  Uhich  Are  Not  Referenced  By  Any  Other  Entry  "" 


DATA-LINE.TABLE  .  .  .  . 
ENCODE D_MESSA6E_BUFFER 
LINE-PROTOCOL-MANAGER  . 
PRI_MBDL_MSG_BLOCK  .  . 
RED_MBDL_MSG_BLOCK  .  . 
SELECT_MESSAGE_F0R_XM1T 


(FILE) 

(FILE) 

(PROCESS  3. 3. 3. 3. 2. 2) 
(FLOW) 

(FLOW) 

(PROCESS  3. 3. 3. 3. 2.1) 


6  UNREFERENCED  ENTRIES  FOUND 
CROSS  CHECK  REPORT  FOR  DD  ‘DRAFT1 

""  Entries  Uhich  Do  Not  Make • Ref e rence  To  Any  Other  Entry 


ENCODED -MESSAGE-BUFFER  ....  (FILE) 
SELECT-MESSAGE-FOR-XMIT  ....  (PROCESS  3. 3. 3. 3. 2.1) 


2  NOREF  ENTRIES  FOUND 
CROSS  CHECK  REPORT  FOR  DD  ‘DRAFT1 

""  Recursively  Defined  Entries  "" 


NO  RECURSIVELY 
EOI  ENCOUNTERED. 


nVoi 

\ 


DEFINED  ENTRIES  FOUND 


Figure  34  -  Data  Dictionary  Example  (Cross  Checking) 
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STRUCTURE  CHART 


As  its  name  implies,  the  structure  chart  is  a  software  design  tech¬ 
nique  that  graphically  presents  data,  control  communication  and 
modules  required  for  program  units  to  work.  The  structure  chart 
accomplishes  two  major  functions:  (1)  it  partitions  the  implied 
software  described  by  the  data  flow  diagrams  and  data  dictionary 
into  a  hierarchy  of  program  units,  each  of  which  is  viewed  as 
performing  a  well  defined  function  in  the  program,  and  (2)  it  es¬ 
tablishes  the  means  and  direction  of  communication  between  program 
units. 

In  keeping  with  the  overall  goal  of  step-wise  refinement,  the  struc¬ 
ture  chart  takes  the  design  one  step  closer  to  a  coding  solution  of 
the  original  problem  by  logically  viewing  each  module  in  its  proper 
place  in  the  emerging  software.  The  logical  view  is  preserved 
because,  in  order  to  create  the  structure  chart,  a  designer  must 
decide  what  functions  are  needed  to  accomplish  the  transformations 
specified  in  the  data  flow  diagram.  These  functions  were  not  viewed 
as  any  particular  physical  entity,  e.g.,  a  subprogram,  they  are  simply 
logical  activities  that  must  take  place  in  order  to  take  the  system 
from  one  data  flow  bubble  to  another.  These  functions,  and  whatever 
subfunctions  they  may  in  turn  be  composed  of,  become  the  module  or 
program  unit  upon  which  the  structure  is  based. 

The  structure  chart  uses  a  symbology  that  is  restricted  to  represen¬ 
tation  of  program  units,  the  logical  relationship  among  program  units 
and  the  communication  between  them.  The  symbol  for  a  program  unit 
is  a  rectangle  identified  by  a  functional  name. 
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The  program  unit  name  should  be  comprised  of  a  descriptive  verb 
and  ideally,  a  single,  nonplural  object  identifying  the  total 
function  of  the  module  or  program  unit.  Use  of  vague,  general 
terms  like  "process"  should  be  avoided  in  program  unit  names.  At 
the  structure  chart  level  a  specific,  non-general,  function  is 
desired.  The  use  of  vague  terms  in  a  program  unit  name  is  a  sian 
that  the  actual  functional  make-up  of  the  transform  has  not  been 
clearly  understood  and  the  named  program  unit  just  parrots  the 
data  flow  diagram  transformation. 

Connectivity  between  program  units  is  indicated  by  an  arrow  that 
is  drawn  from  the  edge  of  one  program  unit  to  the  edge  of  the 
other.  Even  though  the  arrow  head  points  in  only  one  direction, 
from  the  calling  to  the  called  program  unit,  it  is  understood  that 
the  called  program  unit  returns  to  the  calling  program  unit. 


When  one  program  unit  calls  another,  the  calling  program  unit  may 
send  data  or  control  information.  The  called  program  unit  may  pro¬ 
duce  data  and/or  control  information  which  in  turn  is  passed  back 
to  the  calling  program  unit.  For  example,  the  following  two  program 
units  pass  information  in  the  following  manner: 
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The  solid  circle  tail  of  the  arrow  corresponds  to  control  communi¬ 
cations  and  data  communications  is  shown  by  an  open  circle  tail. 

A  structure  chart  is  produced  by  decomposing  a  data  flow  diagram/ 
data  dictionary  into  its  functional  parts,  deciding  on  relationships 
and  communication  among  parts  and  finally  graphically  representing 
the  resulting  information. 

To  initiate  this  technique,  the  data  flow  diagram  is  analyzed  to 
identify  the  central  transformation  or  transformations,  or  in 
other  words,  where  the  data  is  at  its  most  abstract  or  highly 
processed  form.  This  section  becomes  the  second  level  of  the 
structure  chart.  The  first  level  is  completed  by  adding  a  control 
module.  Once  these  upper  levels  of  the  chart  have  been  achieved, 
the  lower  levels  can  be  derived  by  top-down  refinement. 

The  process  of  decomposing  a  data  flow  diagram  transform  into  its 
equivalent  set  of  structure  chart  boxes  is  of  singular  importance 
at  this  state  of  design.  The  functions,  relationships,  and  communi¬ 
cation  produce  the  software  tree  structure  identifying  program 
units  that  will  be  designed  and  coded.  Scheduling  and  management 
of  program  units  can  begin  at  this  point. 


The  following  guidelines  are  recommended  in  the  usage  of  the  struc¬ 
ture  chart  design  tool: 
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•  Unless  otherwise  indicated  a  program  unit  will  be  assumed  to 
have  a  single  entry  point  and  a  single  exit  point. 

•  Program  units  will  be  represented  by  a  rectangle. 

•  Program  units  should  be  identified  by  a  functional  name 
comprised  of  a  descriptive  verb. 

•  Representation  of  program  units  will  be  in  a  hierarchical 
order.  The  high  level  modules  provide  data  to  and  activate 
the  low  level  program  units. 

•  Depending  on  the  programming  language,  program  units  can  appear 
as: 

Packages 

Tasks 

Procedures 

Functions 

Subroutines 

-  Macros 

-  Programs 
Subprograms 

•  Graphics  should  show: 

Program  units 

Calls  between  these  units 

Data  shared  between  them 

As  shown  in  Figures  35  thru  37,  an  automated  structure  chart  tool 
is  available  for  use  on  the  project  to  support  this  software  tech¬ 
nique. 
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Figure  35  -  Structure  Chart  Example 
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TITLE:  "LINE  PROTOCOL  MANAGER  SCT  (REMOTE  COMM) 


PAGE:  391 


Figure  36  -  Structure  Chart  Example 
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TITLE:  TERMINAL  COMMAND  HANDLER  SCT  (REMOTE  COMM) 


PAGE:  302 


i 


REVISION  1 

AUTHOR:  LUD--GIC 

DATE:  2.-18/82 

NOTES: 

\  \ 

CHARACTER  *  \ 

i 

ii ii 


Figure  37  -  Structure  Chart  Example 
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ADA  AS  A  PROGRAM  DESIGN  LANGUAGE 


Coding  in  a  given  language  causes  one  to  seek  problem 
solutions  by  utilizing  the  features  available  in  that 
language.  Similarly,  when  one  uses  a  design  criteria, 
technique,  or  tool,  the  resulting  design  is  biased  toward 
the  features  available.  By  using  a  high  powered  design 
method  and  a  low  level  programming  language,  a  direct  map¬ 
ping  will  occur  but  the  code  may  be  inefficient  because 
some  high  level  programming  language  features  were  not 
available  to  the  designer.  Therefore  a  compatible 
high  powered  program  design  language  should  be  utilized 
with  the  Ada  high  level  language. 

A  Program  Design  Language  (PDL)  can  be  viewed  as  a  com¬ 
bination  of  formally  defined  constructs  known  as  keywords 
derived  from  a  given  programming  language  accompanied  by 
a  set  of  informal  rules.  An  early  attempt  at  such  a 
mechanism  was  set  forth  by  Caine  and  Gordon  (43)  .  The 
purpose  is  to  capture  the  essential  structure  at  a  level 
higher  than  the  implementation  language  itself.  The  re¬ 
sulting  design  should  possess  accuracy  and  precision,  yet 
allow  for  a  flexible  range  of  expressiveness.  In  general, 
PDLs  are  not  intended  to  be  machine  executable.  Figure 
38  which  was  excerpted  from  a  recent  technical  article 

(44)  differentiates  nicely  the  expectations  of  high  order 

* 

languages  and  design  languages. 

This  designer's  guide  will  use  an  Ada-like  program  design 
language  so  that  the  program  solution  will  be  better 
geared  toward  an  Ada  implementation.  The  term  Ada-like 
by  definition  deviates  from  Ada-exact.  The  use  of  the 
GO  TO  and  the  exit  from  a  loop  will  not  be  allowed  in 
program  design.  Any  other  Ada  construct  or  reserved 
word  is  acceptable  and  will  ease  the  transformation  from 
design  to  code.  The  appropriateness  of  utilizing  a  subset 
stems  from  the  ease  of  mapping  the  PDL  into  the  target 
language. 
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High  Level  Language  Design  Language 
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Figure  38  -  Differences  Between  High  Level  Language  and  Design  Language 


As  the  PDL  will  be  utilized  to  design  program  units  shown  on  the 
Structure  Charts,  the  following  guidelines  will  be  used: 

•  Program  units  will  be  designed  to  solve  a  particular  problem 
and  have  logic  which  is  easy  to  describe. 

•  Simple  solutions,  designs  and  interfaces  will  be  utilized. 

•  Program  units  will  be  enclosed  by  identifiable  boundaries. 

•  Program  units  can  only  be  referenced  from  other  parts  of  the 
program  by  its  name. 

•  It  is  desireable  for  program  units  to  have  only  a  single,  common 
entry  and  a  single,  common  exit.  With  tasks  and  task  types  this 
may  not  be  possible. 

•  Program  units  will  be  designed  using  the  top-down  concept. 

•  Logic  flow  will  begin  at  the  top  and  flow  to  one  bottom  exit 
point  except  for  "Exceptions". 

•  Logically  related  program  units  will  be  identified  for  possible 
implementation  as  Ada  packages. 

•  The  comment  mechanism  is  utilized  where  information  can  be  best 
transmitted  for  human  communication  purposes  by  English  text. 

The  largest  difficulty  anticipated  is  the  tendency  to  elevate  all 
the  details  of  the  implementation  language  to  the  PDL  level  of 
abstraction.  For  example,  Figure  39  is  an  illustration  of  a  Program 
Design  Language  based  on  Ada  constructs  and  Figure  40  is  the  actual 
Ada  language  source  code.  This  example  is  adapted  from  a  book  by 
Pyle  (14).  Figure  41  lists  some  of  the  comparative  differences 
between  Ada/PDL  and  Ada  code. 
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generic 

type  DATA_ITEM  is  private 

type  ITEM_KEY  is  —  not  decided  as  yet 

package  DATA_MODULE  is  —  outside  world  view  of  DATA_MODULE 
procedure  READ  (KEY  :  ITEM_KEY ;  DATA  :  out  DATA_ITEM) 
procedure  V7RITE  (KEY  :  ITEM_KEY;  DATA  :  in  DATA_ITEM) 
procedure  UPDATE  (KEY  :  ITEM__KEY ;  NEW  :  in  DATA_ITEM ; 

OLD  :  out  DATA_ITEM) 
procedure  DELETE  (KEY  :  ITEMJKEY) 
function  FIND  (KEY  :  ITEM_KEY)  return  BOOLEAN 
NO_DATA_FOR_KEY ;  OVERWRITE_DUPLICATE_KEY  :  exception 
end  DAT A_MODU  LE 

package  body  DATA_MODULE  is 

task  DATA_MGR  is  —  this  task  will  do  all  of  the  work 
entry  GET  ( 
entry  PUT  ( 
entry  CHANGE  ( 
entry  REMOVE  ( 
entry  I S_THEP.E  ( 
end  DATA_MGR 

procedure  READ  (  )  is 

DATA_MGR . GET  (  ) 

—  if  no  data  item  for  the  key  raise  appropriate  exception 

end  READ 

procedure  WRITE  (  )  is 

DATA_MGR . PUT  (  ) 

—  if  key  is  already  in  use  raise  appropriate  exception 
end  WRITE 


Figure  39  -  Program  Design  Language  (1  of  3) 
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procedure  UPDATE  is 

DATA_MGR. CHANGE 

—  if  no  data  item  for  the  key  raise  appropriate  exception 
end  UPDATE 

procedure  DELETE  (  )  is 

DATA_MGR . REMOVE 

—  if  no  data  item  for  the  key  raise  appropriate  exception 
end  DELETE 

function  FIND  IS 

DATA_MGR. IS_THERE  (KEY,  FOUND  :  out  BOOLEAN) 
return  FOUND 
end  FIND 

task  body  DATA. MGR  is 

DATA_SET  :  —  the  physical  representation  of 
—  DATA_SET  has  not  been  decided 
KEY_IN_USE  :  —  will  depend  on  choice  for  DATA_SET 

—  Note  that  all  entries  will  have  parameters  for  the 

—  random  access  key  and  for  a  Boolean  data  object  to  indicate 

—  the  success  or  failure  of  the  operation.  In  addition,  GET, 

—  PUT  and  CHANGE  will  have  parameters  for  the  data  items  being 

—  passed, 
begin 

loop 

select 

accept  GET  (PARAMETER  LIST) 

if  DATA_SET  HAS  AN  ENTRY  CORRESPONDING  TO  KEY  THEN 
SET  BOOLEAN  PARAMETER  TO  TRUE 
ASSIGN  DATA  ITEM  TO  DATA  PARAMETER 
else  • 

SET  BOOLEAN  PARAMETER  TO  FALSE 
end  if 
end  GET 


or 


Figure  39  -  Program  Design  Language  (2  of  3) 
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accept  PUT  (PARAMETER  LIST) 

if  DATA_SET  HAS  NO  ENTRY  CORRESPONDING  TO  KEY  THEN 
ADD  DATA  ITEM  TO  DATA_SET 
SET  BOOLEAN  PARAMETER  TO  TRUE 

else 

SET  BOOLEAN  PARAMETER  TO  FALSE 
end  if 
end  PUT 
or 

accept  DELETE  (PARAMETER  LIST) 
if  KEY  MATCHES  THEN 

SET  BOOLEAN  TO  TRUE 

else 

SET  BOOLEAN  PARAMETER  TO  FALSE 
end  if 

INDICATE  ENTRY  CORRESPONDING  TO  KEY  IS  AVAILABLE 
END  DELETE 
or 

accept  CHANGE  (PARAMETER  LIST) 
if  KEY  IS  IN  USE  THEN 

RETRIEVE  EXISTING  VALUE  TO  RETURN 
end  if 

INDICATE  THAT  ENTRY  CORRESPONDING  TO  KEY  IS  IN  USE 
STORE  NEW  VALUE 
end  CHANGE 
or 

accept  IS_THERE  (PARAMETER  LIST) 

RETURN  KEY_IN_USE  STATUS 
end  IS_THERE 
or 

terminate 
end  select 
end  loop 
end  DATA_MGR 
end  DATA  MODULE 


Figure  39 _  program  Design  Language  (3  of  3) 
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ADA  SOURCE  CODE 


— Indexed  data  set.  Random  access  Data  module 
— Accessable  to  several  tasks  with  protection  against 
— interference  during  read/write. 

— The  type  of  data  item  and  the  key  should  be 
— fixed  for  any  one  data  set  but  several  different 
— data  items  and  keys  will  be  needed. 

— The  data  module  has  its  own  storage  to  hold 
— the  current  data  items.  Memory  (storage)  elements 
— are  flagged  as  in  use  or  available. 

generic  —  making  package  generic  allows  any  type  for  key  items 
type  DATA_ITEM  is  private;  —  make  up  of  type  is  not  necessary 
type  ITEM__KEY  is  (<  >)  ;  —  key  will  be  a  discrete  type 

package  DATA_MOD'JLE  is  —  operations  allowed  on  data 
procedure  READ  (KEY  :  ITEM_KEY;  DATA  :  out  DATA_ITEM) ; 
procedure  WRITE  (KEY  :  ITEM_KEY;  DATA  :  in  DATA_ITEM) ; 
procedure  UPDATE  (KEY  :  ITEM_KEY ; 

NEW_DATA_ITEM  :  in  DATA_ITEM; 

OLD_D  AT  A  _I  TEM  ;  OUt  DATA_ITEM)  ; 
procedure  DELETE  (KEY  :  ITEM_KEY) ; 
function  FIND  (KEY  :  ITEM_KEY)  return  BOOLEAN; 

NO_DATA_FOR_KEY,  DUPLICATE_KEY_OVERITE  :  exception; 
end  DATA_MODULE; 

package  body  DATA_MODULE  is 

task  DATAJKANAGER  is  — The  entries  provide  the  only 

— interface  to  the  actual 
— data.  Making  this  access 
— module  a  task  provides  inter- 
— ference  protection  and 
— queueing  of  requests. 

entry  GET  (KEY  :  ITEM_KEY;  DATA  :  out  DATA_ITEM; 

FOUND  :  out  BOOLEAN) ; 


Figure  40  -  Ada  Language  Source  Code  (1  of  4) 
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entry  PUT  (KEY  :  ITEM_KEY;  DATA  :  in  DATA_ITEM; 

FOUND  :  out  BOOLEAN) ; 

entry  CHANGE  (KEY  :  ITEMJCEY;  NEW  :  in  ITEM; 

OLD  ;  out  ITEM;  FOUND  :  out  BOOLEAN) ; 
entry  IS_TKERE  (KEY  ;  ITEMJCEY;  FOUND  :  out  BOOLEAN) ; 
entry  REMOVE  (KEY  :  ITEM_KEY;  FOUND  ;  out  BOOLEAN); 
END  DATA  MANAGER; 


— The  remainder  of  the  package  body  is  the 
— implementation  of  the  specification  section. 

procedure  READ  (KEY  :  ITEM_KEY ;  DATA  :  out  DATA_ITEM)  is 
FOUND  ;  BOOLEAN; 

begin 

DATA_MANAGER . GET  (KEY,  DATA,  FOUND); 
if  not  FOUND  then 

raise  NO_DATA_FOR_KE Y ; 
end  if; 
end  READ ; 

procedure  WRITE  (KEY  :  ITEM_KEY;  DATA  ;  in  DATA_ITEM)  is 
KEY_IN_USE  :  BOOLEAN; 
begin 

DATA_MANAGER . PUT  (KEY,  DATA,  KEY_IN_USE) ; 
if  KEY_IN_USE  then 

raise  DUPLICATE_KEY_OVERITE ; 
end  if; 

end  WRITE; 

procedure  UPDATE  (KEY  :  ITEM_KEY;  NEW_D ATA_I TEM  :  in  DATA_ITEM) 

OLD_DATE_ITEM  :  out  DATA_ITEH)  is 
FOUND  :  BOOLEAN; 

DAT A_MANAGER. CHANGE  (KEY,  NEW_D AT A_I TEM ,  OLD_DATA_ITEM , 

FOUND) ; 

if  not  FOUND  then 

raise  NO_DATA_FOR_KEY ; 
end  if 

end  UPDATE; 

Figure  40  -  Ada  Language  Source  Code  (2  of  4) 
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procedure  DELETE  (KEY  :  ITEM_KEY)  is 
FOUND  :  BOOLEAN; 

begin 

DATA_MANAGER . REMOVE  (KEY,  FOUND); 
if  not  FOUND  then 

raise  NO_DATA_FOR_KEY ; 
end  if; 
end  DELETE; 

function  FIND  (KEY  :  ITEM_KEY)  return  BOOLEAN  is 
FOUND  :  BOOLEAN; 
begin 

DATAJ1ANAGER . I S_THERE  ( KE Y ,  FOUND ) ; 
return  FOUND; 

end  FIND; 

task  body  DATA_MANAGER  is 

DATA_SET  :  array  (KEY)  of  DATA_ITEM; 

KEY_IN_USE  :  array  (KEY)  of  BOOLEAN  :=  (others  =>  FALSE) ; 

begin 

loop 

select 

accept  GET  (KEY  :  ITEM_KEY ;  DATA  :  out  DATA_ITEM 
FOUND  :  out  BOOLEAN) ; 
do 

FOUND  :=  KEY_IN_USE  (KEY); 
if  FOUND  then 

DATA  :=  DATA_SET  (KEY); 
end  if; 
end  GET; 
or 

accept  PUT  (KEY  :  ITEM_KEY ;  DATA  :  in  DATA_ITEM 
FOUND  :  out  BOOLEAN) 
do 


Figure  40-  Ada  Language  Source  Code  (3  of  4) 


FOUND  :=  KEY_IN_USE  (KEY); 

DATA_SET  (KEY)  :=  DATA; 

IN_USE  (KEY)  :=  TRUE; 
end  PUT 
or 

accept  CHANGE  (KEY  :  DATA_KEY;  NEW  :  in  DATA_MIND) ; 
OLD  :  out  DATA_ITEM;  FOUND  :  out  BOOLEAN) ; 
do 


FOUND  :=  KEY_IN_USE  (KEY); 
if  FOUND  then 

OLD  :=  DATA_SET  (KEY); 
end  if 

DATA_SET  (KEY)  :=  NEW; 

KEY_IN_USE  (KEY)  :=  TRUE; 
end  CHANGE; 
or 

accept  DELETE  (KEY  :  ITEM_KEY;  FOUND  :  out  BOOLEAN); 
do 

FOUND  ;=  KEY_IN_USE  (KEY) ; 

KEY_IN_USE  (KEY)  :=  FALSE; 
end  DELETE; 
or 

accept  IS_THERE  (KEY  :  ITEM_KEY;  FOUND  :  out  BOOLEAN) 
do 

FOUND  :=  KEY_IN_USE  (K) ; 
end  IS_THERE; 
or 

terminate 

end  loop; 
end  DATA_MANAGER; 
end  DATA  MODULE; 


Figure  40  -  Ada  Language  Source  Code  (4  of  4) 


Ada/PDL  Compared  to  Ada  Code 


1.  The  type  of  key  to  be  used  to  access  the  data  set  has 
not  been  decided. 

2.  The  specification  section  of  the  package  DATA_MODULE 
is  identical  in  both  PDL  and  code.  This  is  necessary 
because  this  specification  is  the  view  of  this  package 
from  the  outside  world.  At  the  PDL  stage  this  view  must 
be  layed  out  in  enough  detail  to  allow  other  parts  of 
the  system  to  be  written.  Any  lower  level  detail  is 
invisible  to  the  rest  of  the  system. 

3.  The  entry  points  listed  in  the  task  specification  for 
task  DATA_MANAGER  will  do  the  work  of  dealing  with  the 
actual  data.  At  the  PDL  stage  the  arguments  for  these 
entries  have  not  been  decided  upon.  Design  can  continue 
however,  because  the  PDL  just  wants  to  show  how  these 
entries  are  used.  Exactly  how  the  entries  work  can  be 
left  until  code  time. 

4.  The  procedure  "bodies"  make  use  of  the  parameterless 
entry  points  to  show  the  connection  between  the  logical 
and  physical  levels  of  data  management. 

5.  Comments  in  the  procedure  "bodies"  explain  some  things  that 
will  need  to  be  coded  during  coding,  but  are  of  passing 
interest  only  at  this  stage. 

6.  A  major  difference  between  the  PDL  and  code  is  the  fact 
that  the  actual  organization  of  the  data  structure  has 
not  been  decided  at  the  PDL  level.  This  fact  points 

out  a  great  strength  in  an  Ada/PDL.  The  PDL  can  continue 
with  the  task  description  without  needing  to  know  what  it 
is  really  dealing  with.  The  PDL  simply  uses  the  abstract 
idea  of  a  data  pool,  the  decision  as  to  what  this  data 
pool  will  be  (e.g.,  an  array,  a  linked  list,  a  stack,  etc.), 
can  be  put  off  until  the  code  section.  Since  the  actual 
data  structure  is  confined  to  the  task  body  for  DAT ^_MANAGE R 
it  is  invisible  to  all  higher  level  program  units  so  any 
change  in  data  structure  will  not  effect  anything  but  the 
task  body. 

7.  The  entries  for  task  body  DATA_MANAGER  are  completely 
described  because  they  deal  with  the  abstract  representation 
of  the  data.  The  code  for  these  entries  is  not  complete 
because  without  knowing  what  type  of  data  structure  you  are 
dealing  with  you  cannot  write  code  to  manipulate  it  physically. 


Figure  41  -  PDL  and  Ada  Code  Differences 
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When  the  PDL  for  a  program  unit  is  finished,  the  following 
criteria  characterizing  good  design  should  be  represented 
in  the  resulting  modular  or  program  units.  The  term 
module  is  used  in  the  description  as  it  is  generally 
under stood. 

Coupling  is  a  measure  of  module  interdependence;  i.e., 
the  extent  to  which  an  error  or  change  in  one  module  will 
cause  an  error  or  necessitate  a  change  in  another  module. 
It  should  be  apparent  that  in  a  system  with  a  great  deal 
of  module  interdependence,  called  tightly  coupled,  errors 
or  changes  in  any  part  of  the  system  will  resonate  or 
ripple  through  the  entire  system  causing  more  errors 
and  changes.  Coupling  is  probably  the  most  important 
of  the  design  qualities  because  of  the  far  reaching 
consequences  if  done  poorly.  Because  of  this  impor¬ 
tance,  the  coupling  resulting  from  Data  Flow  Diagram 
decomposition  should  be  closely  reviewed  to  create 
maximum  looseness  before  the  design  process  moves  to 
the  next  stage. 


Cohesion  is  a  measure  of  the  single  mindedness  of  a  mod¬ 
ule.  A  highly  cohesive  module  concerns  itself  with 
accomplishing  one  function  only.  As  with  coupling,  it 
should  be  apparent  that  a  module  with  low  cohesiveness 
can  propagate  an  error  or  change  in  one  of  its  functions 
to  all  of  its  other  functions.  Ideally  a  highly  cohesive 
module  should  appear  like  a  black  box  to  any  other  module 
that  wishes  to  use  it. 

State  Memory  is  global  data.  Because  shared  data  can  act 
as  a  conduit  through  which  errors  and/or  changes  can  prop¬ 
agate  from  one  module  to  another,  state  memory  undesire- 
ably  increases  coupling.  Ideally,  there  should  be  no 
global  data,  but  if  its  use  cannot  be  avoided  it  should  be 
restricted  to  read-only  use  to  minimize  the  coupling  effect. 
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Module  Size,  it  has  long  been  noted  that  limiting  module  source 
code  size  helps  insure  module  independence,  readability,  test¬ 
ability,  and  maintainability.  IBM,  on  the  New  York  Times  Project 
limited  modules  to  50  lines  of  source  code  and  TRW  has  recommended 
modules  be  no  longer  than  two  (2)  print  pages  in  length.  This 
quantitative  limit  is  especially  important  in  the  maintenance 
phase  where  human  beings  are  directly  concerned  with  comprehend- 
ability.  In  order  to  change  code  without  some  inadvertant  conse¬ 
quences  taking  place,  the  effected  sections  must  be  precisely 
comprehended.  Therefore,  guidelines  for  module  design  will  be, 
not  only  designed  with  loose  coupling  and  high  cohesion,  but 
limited  to  between  ten  and  fifty  high  order  language  statements. 

Measure  of  Complexity,  the  technique  used  to  measure  the  complexity 
of  a  program  unit  and  explained  in  the  succeeding  section,  will 
be  used  to  assist  designing  uncomplicated  program  units. 

When  the  structure  charts  have  been  developed  initially,  the  pro¬ 
bability  of  exact  correctness  is  extremely  low.  It  is  through 
the  generation  of  the  PDL  in  the  design  of  the  module/program 
unit  that  the  correctness  will  be  determined.  Hence  the  structure 
chart  will  have  to  be  updated  due  to  units  being  too  large,  too 
small,  tight  coupling  or  low  cohesion.  Some  of  the  terms  and 
action  that  can  result  from  PDL  generation  causing  the  structure 
charts  to  be  updated  are: 

Factoring  is  the  decomposition  of  a  large,  low  cohesive  module  into 
submodules.  Factoring  is  often  all  that  is  needed  to  increase 
cohesion  because  one  module  with  poor  cohesion,  as  a  result  of 
trying  to  do  too  many  things,  can  be  factored  into  several  modules 
that  each  perform  one  specific  function. 

Decision  Splitting  is  the  separation  of  a  decision  from  the  action, 
resulting  from  that  decision.  Decision  splitting  reduced  cohesion 
and  increases  coupling,  but  is  easily  remedied  by  simply  unsplitting 
the  decision. 
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Fan/Out,  or  the  number  of  submodules  any  one  module  has 
should  be  restricted  to  a  maximum  of  seven.  If  a  pre¬ 
liminary  design  yields  a  higher  fan/out  some  factoring 
to  yield  at  lease  one  more  level  is  necessary. 

Fan/ In,  or  the  number  of  masters  that  use  any  one  slave 
module,  should  be  as  high  as  possible.  High  fan/in 
results  from  effectively  factoring  a  common  function  out 
of  all  the  modules  in  which  it  appears. 

Error  Reporting  should  be  done  at  the  point  of  error 
discovery  not  at  a  centralized  error  handling  location. 
The  Ada  language  provides  the  Exception  facility  for 
both  predefined  and  user  defined  Exceptions  which  may  be 
raised  during  the  execution  of  statements. 

Complexity  Measure  is  an  indication  of  the  program  unit's 
simple  or  complex  design  and  is  explained  in  the  next 
section.  Calculations  of  this  measure  should  produce 
an  indication  as  low  as  possible. 
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ADA/PDL  SYNTAX  DIAGRAMS 
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IF-THEN-ELSIF-ELSE 

The  If-Then-Elsif-Else  statement  causes  control  to  be 
transferred  to  one  or  none  of  a  number  of  sequences 
of  statements  based  on  the  evaluation  of  the  truth  of 
a  conditional  statement. 


if  (p)  then 
English  language 
elsif  (q)  then 
English  language 


elsif  (r)  then 
English  language 
else 

English  lang  .age 
end  if; 

LOOP  STATEMENT 

The  loop  statement  specifies  a  sequence  of  statements 
to  be  executed  repeatedly  zero  or  more  times. 
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♦  TYPE  Q73.SDL 
procedure  TSQ-73  is 

—  The  objective  of  the  Missile  Minder  (AN/TSQ-73) 

— system  is  the  Air  Defense  command  and  control 

— system  designed  to  coordinate  the  actions  of 
— HAWK* IMPROVED  HAWK*  and  NIKE/HERCULES  surface 
— to  air  aissiles  against  hostile  air  targets* 

— The  system  is  fielded  in  two  configurations*  the 
— GROUP/BDE-level  system  and  the  BATALLION/BN-level 
— system . 

The  mission  of  the  GROUP/BDE-level  system 
— concentrates  on  the  monitoring  of  Air  Defense 
— activities  of  subordinate  BN-level  systems* 

— allocation  and  asignment  of  Air  Defense  resources* 

— Planning  Air  Defense  operations*  supervising  the 
— effectiveness  of  real-time  Air  Defense  resources* 

— serving  as  the  tactical  operations  center  for  group 
— operations  *  and  interfacing  with  other  GROUP-level 
— MISSILE  MINDER  systems*  other  Army  tactical  command 
— and  control  systems*  and  tactical  command  and 
— control  systems  of  other  military  services. 

The  mission  of  the  BATTALION/BN-level  configuration 
— is  to  control  the  actual  direction  of  the  air  battle 
— with  its  execution  being  conducted  at  the  fire  unit 
— level.  The  BN-level  system  acquires* tracks*  and 

—  identifies  ai rcraft *  provides  real-time  threat 
— evaluation  and  weapons  assignment  for  hostile 

— aircraft  engagement*  and  provides  friendly  aircraft 
— protection.  A  BN-level  system  can  be  designated  as  a 
— master  BN-level  system  when  a  GROUP/BDE-level  system 
— is  inoperable  or  non-existent  due  to  local  conditions. 

— The  designated  master  BN-level  system  will  provide  the 
— interface  to  other  Army  tactical  data  systems  and  tactical 
— command  and  control  systems  of  other  military  services. 

The  TSQ-73  operator  shall  select  either  the  GROUP 
— configuration  or  the  BATTALION  configuration  at  runtime 
— initialization  (site  adaptation).  The  redesign  of  the 
— TSQ-73  has  been  limited  to  the  BATTALION  (BN) 

— configuration.  The  TSQ-73  has  been  repartitioned  to 
— reveal  four  concurrent  processes! 
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$  TYPE  COHCON  »  SDL 

package  COMMAND  AND  CONTROL  (1.0)  is 

—  The  COMMAND  AND  CONTROL  package  controls  the 
— total  system  resources  and  allocates  them  to  the 
— various  tasks  in  the  TSQ-73  system.  The  COMMAND 

— AND  CONTROL  package  incorporates  a  number  of  utilities 
— which  will  reduce  application  development  timer  exercise 
— the  various  application  packages  within  the  TSQ-73  and 
— provide  a  friendly  interface  between  the  operators  and 
—the  TSQ-73  system.  The  COMMAND  AND  CONTROL  package 
— consists  oft 

package  GENERAL  OPERATING  SYSTEM  <1.1)1 
package  RUNTIME  SUPPORT  SOFTWARE  <1.2)5 
package  RUNTIME  INITIALIZATION  <1.3)5 
package  USER  APPLICATION  LIBRRY  <1.4)5 
package  I/O  MESSAGE  INTERPRETER  <1.5)5 
package  RUNTIME  TERMINATION  <1.6)5 
package  RUNTIME  SYSTEM  EXERCISOR  <1.7)5 

—  A  subset  of  the  COMMAND  AND  CONTROL  package  will  be 
— utilized  by  local » remote  and  radar  communication 

— processors • 

It  is  not  the  intent  of  the  COMMAND  AND  CONTROL  SDL 
— to  be  complete.  Its  intent  is  to  provide  an  outline 

—  for  COMMAND  AND  CONTROL  and  to  be  utilized  as  a 

— reference  as  to  what  is  contained  within  the  package. 

— This  is  primarily  due  to  the  limited  resources  allocated 
— to  it  under  the  existing  contract. 


package  GENERAL  OPERATING  SYSTEM  <1,1>  is 

The  operating  system  is  a  general-purposermulti-taskingr 
— event-driven.secondary-storaSe-based  system  that  controls 

—  the  system  resources  for  real-timer  time-sharing  and 

— batch  applications.  A  subset  of  the  general  operating 
--system  will  be  utilized  for  the  runtime  operating  system. 

—  The  GENERAL  OPERATING  SYSTEM  consists  oft 
package  SYSTEM  BOOTSTRAP  INITIALIZATION  <1.1.1)  5 
package  RESOURCE  MANAGEMENT  <1.1.2)  5 

package  TASK  MANAGEMENT  (1.1. 3) 5 
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package  TASK  COMMUNICATION  (1.1,4)? 
package  POWER  FAIL/AUTOMATIC  RESTART  (1.1.5)? 
package  DEVICE  I/O  HANDLERS  (1,1.6)? 
psckeae  FILE  MANAGEMENT  (1.1.7)? 

package  ERROR  RECOVERY  AND  SYSTEM  REPORTING  (1.1.8)? 
package  SYSTEM  COMMAND  INTERPRETER  (1.1.9)? 
package  MAINTENANCE  AND  DIAGNOSTICS  UTILITIES  (1.1.10)? 
end  GENERAL  OPERATING  SYSTEM  (1.1)? 

package  body  GENERAL  OPERATING  SYSTEM  (1.1)  is 
package  SYSTEM  BOOTSTRAP  INITIALIZATION  (1.1.1)  is 

-  SYSTEM  BOOTSTRAP  INITIALIZATION  performs  3  system 
-boostrsp  initialization  from  a  cold  start  (the  section 
-on  POWER  FAIL/AUTOMATIC  RESTART  and  INTERRUPT  MANAGEMENT). 
-This  is  accomplished  by  a  hardware  interrupt  processor 
-RESET  switch.  A  preliminary  set  of  hardware  diagnostic 
-routines  are  executed  on  the  processor * memory * 

-controllers  and  interfaces!  system  console  and  peripheral 
-devices*  etc.  Hardware  faults*  if  any*  will  be  identified 
-along  with  the  reason  for  their  fault.  These  faults  will 
-be  displayed  by  means  oft 

-system  console 
-status  display  panel 

-  -processor  front  panel  indicators 
-error  lamps  on  the  malfunctioning  board 

( processo  r*controller*interface*  memory  *peripheral 
etc .  ) 

NOTE.  Each  of  the  following  packages*  procedures* 
-functions  or  tasks  would  have  an  associated  description, 
procedure  EXECUTES  INITIAL  START-UP  PROCEDURES  (1.1. 1.1) 

-  Read-Only-Memory  (ROM)  routines, 
procedure  LIGHTS  PROCESSOR(S)  FRONT  PANEL  POWER  ON 

INDICATOR  (1,1. 1,1,1)? 

procedure  TEST  POWER  FAIL/AUTOMATIC  RESTART  INDICATORS 

(1. 1.1.1, 2)  ? 

procedure  SYNCHRONIZE  DATA  CHANNEL  BUSES  (1.1. 1.1. 3)? 
procedure  LIGHT  HARDWARE  FAULT  INDICATORS  (1.1. 1.1. 4)? 
procedure  PRELIMINARY  HARDWARE  DIAGNOSTICS  (1.1. 1.1. 5)? 
procedure  INITIALIZE  POWER  FAIL/AUTOMATIC  RESTART 
INDICATORS  (1,1. 1.1.6)? 


procedure  EXTINGUISH  HARDWARE  FAULT  INDICATORS 
(1.1. 1.1. 7>? 

Extinguish  only  hardware  fault  indicators  that  have 
— successfully  passed  the  preliminary  hardware  diagnostics, 
procedure  START  MAINTENANCE  AND  DIAGNOSTICS  PROCESSOR 
(1.1. 1.1. 8)} 

end  EXECUTES  INITIAL  START-UP  PROCEDURES  (1. 1.1.1)} 

procedure  LOADS  AND  EXECUTES  OPERATING  SYSTEM  (1.1. 1.2)  is 
—OS  is  GENERAL  OPERATING  SYSTEM 

procedure  IDENTIFIES  OS  SOURCE  LOCATION  (1.1. 1.2.1)} 
procedure  INITIALIZES  OS  SOURCE  LOCATION  DEVICE 
(1.1. 1.2. 2)} 

procedure  LOADS  OS  INTO  MEMEORY  (1.1. 1.2. 3)} 
procedure  STARTS  OS  EXECUTION  (1.1. 1.2. 4)} 
end  LOADS  AND  EXECUTES  OPERATING  SYSTEM  (1.1. 1.2)} 

procedure  INITIALIZE  SYSTEM  CONSOLE  DEVICE  (1.1. 1.3)  is 
procedure  CONSOLE  DEVICE  DETERMINATION  (1.1. 1.3.1)} 
procedure  OPEN  CONSOLE  DEVICE  FOR  I/O  (1.1. 1.3. 2)} 
procedure  REPORT  CURRENT  SYSTEM  STATUS  (1.1. 1.3. 3)} 

Status  includes  date,  timer  CPU  identification  codes? 

— hardware  faults  (if  any)?  operating  system  version? 

— software  exceptions ? etc ♦ 

end  INITIALIZE  SYSTEM  CONSOLE  DEVICE  (1.1. 1.3)} 

procedure  INITIALIZE  SYSTEM  LOG  (1.1. 1.4)  is 
procedure  SYSTEM  LOG  DEVICE  DETERMINATION  (1.1. 1.4.1)} 
procedure  OPEN  SYSTM  LOG  DEVICE  FOR  I/O  (1.1.1. 4. 2)} 
procedure  REPORT  CURRENT  SYSTEM  STATUS  (1.1. 1.4. 3)} 

Status  includes  date? timerCPU  identification  codes? 

— hardware  faults  (if  any)?  operating  system  version? 

— software  exceptions?  etc. 

end  INITIALIZE  SYSTEM  LOG  (1.1. 1.4)} 

procedure  INITIALIZE  REMAINING  PERIPHERALS  (1.1. 1.5)  is 
This  procedure  will  initialize  the  remaining  peripheral 
— devices}  secondary-storage  devices  (if  not  initialized  for 
— system  bootstrap)?  magnetic  tape  devices  (if  not 
— initialized  for  system  bootstrap)?  display  consoles? 
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-auxiliary  read-outs »  status  display  panels*  etc. 

procedure  PERIPHERAL  DEVICE  DETERMINATION  (1.1.1. 5*1) f 
procedure  OPEN  PERIPHERAL  DEVICE  FOR  I/O  <1.1. 1.5. 2)5 
Devices  are  opened  based  upon  characteristics,  that  is. 
-devices  only  capable  of  output  are  only  opened  for 
-output.etc . 

procedure  REPORT  CURRENT  SYSTEM  STATUS  (1.1. 1.5. 3)} 

Only  for  status  display  panels* 
end  INITIALIZE  REMAINING  PERIPHERALS  (1.1. 1.5)*. 

procedure  INITIALIZE  SYSTEM  COPROCESSORS  <1.1. 1.6)  is 
Siniliar  to  the  procedures  described  in  EXECUTES 
INITIAL  START-UP  PROCEDURES  (1.1.1. 1)  with  the  addition 
-  that  the  coprocessors  may  be  downline  loaded, 
end  INITIALIZE  SYSTEM  COPROCESSORS  <1. 1. 1.6)1 

procedure  LOAD  AND  EXECUTE  SYSTEM  COMMAND  INTERPRETER 

(1.1. 1.7)  is 

procedure  IDENTIFIES  SYSTEM  COMMAND  INTERPRETER  LOCATION 
<1.1. 1.7.1)} 

procedure  LOADS  SYSTEM  COMMMAND  INTERPRETER  INTO  MEMORY 

(1.1. 1.7.2)  } 

Initializes  source  location  device  if  necessary, 
procedure  START  SYSTEM  COMMMAND  INTERPRETER  EXECUTION 

(1.1. 1.7. 3)  ) 

end  LOAD  AND  EXECUTE  SYSTEM  COMMMAND  INTERPRETER 

(1.1. 1.7)  } 

end  SYSTEM  BOOTSTRAP  INITIALIZATION  (1.1.1)} 

package  body  SYSTEM  BOOTSTRAP  INITIALIZATION  (1.1.1)  is 

package  body  would  be  placed  here 

end  SYSTEM  BOOTSTRAP  INITIALIZATION  (1.1.1)} 


package  RESOURCE  MANAGEMENT  (1.1.2)  is 

RESOURCE  MANAGEMENT  performs  the  management  of  all  the 

system's  resources 

procedure  PROCESSOR  MANAGEMENT  <1.1. 2.1)} 
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—  PROCESSOR  MANAGEMENT  (1.1. 2.1)  supervises ? coordinates 
— and  Manases  the  processor's  resources  with  the  other 
— resource  Managers  as  well  as  provide  for  instruction 
— execution? instruction  pref etching?  etc. 

procedure  MEMORY  MANAGEMENT  <1.1. 2. 2)5 

—  MEMORY  MANAGEMENT  provides  resources  fort 

-address  relocation  translation 
-storage  protection 
-stacking  facilities 
-dynamic  memory  Management 
-static  memeory  management 
-sastem  common  management 

procedure  INTERRUPT  MANAGEMENT  (1.1. 2. 3)?* 

—  INTERRUPT  MANAGEMENT  processes  I/O  interrupts  and 
— exception  interrupts.  I/O  interrupts  are  priority 
— interrupts  from  peripheral  I/O  devices  and  sensor 
— I/O  devices.  Exception  interrupt  handlers  process 

— interrupts  from  errors  or  exceptions  which  consist  oft 
-processor  front-panel  switches 
-processor  checks 
-power/ thermal  warnings 
-software  exceptions 
-system(supervisor )  calls 

procedure  TIME  MANAGEMENT  (1.1, 2. 4)1 
The  services  of  TIME  MANAGEMENT  ere! 

-date 

-time  of  day 

-event  or  interval  timers 
-programmable  timers 

The  services  are  provided  for  time  and  date  dependent 
— operations . 


procedure  PERIPHERAL  MANAGEMENT  (1.1. 2. 5)5 
PERIPHERAL  MANAGEMENT  supervises?coordinates  and 
— manages  the  following  peripheral  devices. 

-system  consoles 
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-secondary  storage  units 
-magnetic  tape  units 
-display  consoles 
-auxiliary  read-out 
-status  display  panels 
-processor  front  panel 
-error  lamp  indicators 


procedure  COPROCESSOR  MANAGEMENT  (1.1. 2.6)$ 

•  COPROCESSOR  MANAGEMENT  supervises?  coordinates  and 
-manages  attached  floating-point  processors  and 
-attached  I/O  computers  within  the  system  configuration? 

end  RESOURCE  MANAGEMENT  (1.1.2) $ 

package  body  RESOURCE  MANAGEMENT  (1.1.2)  is 
-package  body  would  be  placed  here 
end  RESOURCE  MANAGEMENT  (1.1.2)$ 


package  TASK  MANAGEMENT  (1.1.3)  is 

TASK  MANAGEMENT  supervises?  coordinates?  schedules 
and  manages  all  tasks  for  execution.  TASK  MANAGEMENT 
■supports  multi-programming  which  allows  more  than  one 
task  to  be  executing  in  the  same  processor  concurrently 
■These  concurrent  tasks  must  share  CPU  time  through  a 
scheduling  policy.  The  scheduling  policy  treats 
differently  the  scheduling  of  devices  and  non-device 
tasks  with  the  same  priority. 

package  TASK  CHARACTERISTICS  MANAGER  (1.1. 3.1)  is 
procedure  TASK  TYPE  (1.1. 3. 1.1)$ 
procedure  TASK  STATUS  (1.1. 3. 1.2)$ 
procedure  TASK  PRIORITY  (1,1. 3.1.3)$ 
procedure  SITE  EXECUTION  LOCATION  DETERMINATION 
(1.1. 3. 1.4) $ 

procedure  CRITICAL  TASKS  (1.1, 3. 1.5)$ 
end  TASK  CHARACTERISTICS  MANAGER  (1.1. 3.1)$ 
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package  TASK  SCHEDULE  POLICY  MANAGER  < 1. 1,3.2) $ 
package  TASK  SYNC  MANAGER  (1. 1.3.3)$ 
package  TASK  INVOCATION  (1.1. 3.4)$ 
package  TASK  SUSPENSION  (1.1. 3.5)$ 
package  TASK  RESUMATION  (1.1. 3.6)$ 
package  TASK  TERMINATION  (1.1. 3.7)$ 
package  TASK  CREATION  (1. 1.3.8)$ 
package  TASK  DELETION  (1.1. 3.9)$ 
end  TASK  MANAGEMENT  (1.1.3)$ 

package  body  TASK  MANAGEMENT  (1.1.3)  is 
— package  body  would  be  placed  here 
end  TASK  MANAGEMENT  (1.1.3)$ 


package  TASK  COMMUNICATION  (1.1.4)  is 

TASK  COMMUNICATION  supervises!  coordinates  and  manages 
— various  mechanisms  available  for  task  communications, 
package  LOU  LEVEL  (1.1. 4.1)  is 
procedure  DEVICE  COMM  WITH  I/O  BUS  (1.1. 4. 1.1)$ 
procedure  DEVICE  COMM  UITH  MEMORY  I/O  BUS  (1.1. 4. 1.2)$ 
procedure  INTERTASK  COMM  UITH  SHARED  VARIABLES  (1.1. 4. 1.3) 
The  simplest  form  of  intertask  communications  is 
— accomplished  through  the  sharing  of  variables  or  records. 

— However*  only  a  single  task  should  be  allowed  to  operate 
— on  a  variable  at  a  time.  A  semaphore  is  used  to 
— guarantee  exclusive  access. 

procedure  INTERTASK  COMM  UITH  MSG  BUFFER  (1.1. 4. 1.4)$ 

A  message  buffer  is  a  shared  data  structure  through 
— which  messages  are  transferred  and  buffered  among  tasks. 

— A  message  is  any  data  structure  ( integer  *  real  *  character » 

— arrays* records  or  pointers)  which  can  be  copied  from 
— one  task  to  another.  A  semaphore  is  used  to  guarantee 
— exlusive  access. 

end  LOU  LEVEL  (1.1. 4.1)$ 


package  HIGH  LEVEL  (1.1. 4. 2)  is 


procedure  CHANNELS  <1*1. 4. 2.1)1 

CHANNELS  provide  message  transmission  from  more  than 
— one  task  to  one  or  more  tasks.  Messages  are  any  data 
— structure  (integer*  real .character  *  arrays  *  records  or 
— pointers).  A  message  can  be  transmitted  more  than  once. 

— Messages  are  transmitted  over  channels.  A  channel 
— synchronizes  and  buffers  message  flow  between  two  or  more 
— processes.  Semaphores  may  be  used  to  guarantee  exclusive 
— access . 

procedure  FILES  (1.1. 4.2.2)* 

FILES  provides  a  real-time  memory  interface  for  logical 
— I/O.  (Reference  section  1.1.7  for  logical  I/O.) 

— Cooperating  tasks  may  communicate  with  each  other!  one 
— task  may  read  file  components  whichare  being  written 
— concurrently  by  another  task.  The  input  is  generated  and 
— the  output  consumed  in  memory  by  tasks  rather  than  waiting 
— for  the  data  to  be  stored  onto  and  retrieved  from  some 
— secondary  storage  device. 

procedure  INTRASYSTEM  TRANSFER  (1.1. 4. 2. 3) 5 
end  HIGH  LEVEL  (1. 1.4.2)* 
end  TASK  COMMUNICATION  (1.1. 4)1 


package  POWER  FAIL  AUTO  RESTART  (1.1.5)  is 
procedure  POWER  FAIL  (1.1. 5.1)* 
procedure  AUTO  RESTART  (1.1. 5. 2)* 
end  POWER  FAIL  AUTO  RESTART  (1.1.5)** 


package  DEVICE  I/O  HANDLERS ( 1 . 1 . 6 )  is 

The  DEVICE  I/O  HANDLERS  package  provices  a  physical 
— device  I/O  interface*  a  physical  to  logical  interface  and 
— logical  device  channels.  Physical  devices  are* 


-system  console 
-secondary  storage  unit 
-magnetic  tape  unit 
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-display  console 
-auxiliary  read-out 
-status  display  panel 
-processor  front  panel 

procedure  PHYSICL  DEVICE  INTERFACE ( 1 . 1 . 6 . 1 > $ 
procedure  PHYSICAL  TO  LOGICAL  INTERFACE  (1.1. 6*2) $ 
procedure  LOGICAL  DEVICE  CHANNELS  (1.1. 6.3)$ 
end  DEVICE  I/O  HANDLERS  (1.1.6)  $ 


package  FILE  MANAGEMENT  (1.1.7)  is 

FILE  MANAGMENT  manages  the  physical  and  logical 
— organization  of  information.  Physical  organization 
— matches  data  to  the  reauirements  of  the  physical  device 
— with  no  regard  to  the  data  content  or  use.  Logical 
— organization  matches  data  to  the  reouirements  of  the  user 
— by  associating  and  grouping  information  according  to 
— content  or  meaning. 

—  FILE  MANAGEMENT  also  manages  the  recording. retrieving? 
— access  methods  and  access  privileges  to  data. 

procedure  DATA  STRUCTURES  (1,1. 7.1)? 
package  FILE  MANAGER  (1.1. 7.2)$ 
package  FILE  MANAGER  UTILITIES  (1,1. 7,3)$ 
procedure  FILES  TO  LOGICAL  DEVICE  CHANNEL  (1.1. 7.4)$ 
end  FILE  MANAGEMENT  (1.1.7)$ 


package  ERROR  RECOVERY  t  SYSTEM  REPORTING  (1.1.8)  is 
package  ERROR  RECOVERY  (1.1. 8.1)$ 

ERROR  RECOVERY  provides  the  ability  to  identify  and 
— deal  with  exceptions  end  the  possibility  of  recovering 
— from  these  exceptions.  ERROR  RECOVERY  provides  fort 

—  -task  errors 

—  -scheduling  errors 
-semaphore  errors 

—  -interrupt  errors 
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--  “device  I/O  errors 

>M*ory  management  errors 
-file  management  errors 

-user  errors  ____ 

-exception  errors 
-processor  errors 

-hardwrre  errors  '  ; 

For  device  I/O  errors;  several  attempts  will  be  made 
— to  successfully  complete  the  I/O  operation  before  the  ^ 

— error  is  considered  valid* 

procedure  SYSTEM  REPORTING  <1.1. 8. 2) t 
SYSTEM  REPORTING  provides  for  the  reporting  of 
— errors  to  the  system  console*  status  display  panel 
— (hardware  only )* display  console*  and  the  system  log. 

— Date  and  time  stamps  are  appended  to  the  error  messages. 

—  Application  programs  and  the  SYSTEM  COMMAND  INTERPRETER  *"5 

— can  specify  additional  message  to  be  recorded  in  the 
--system  log. 

end  ERROR  RECOVERY  t  SYSTEM  REPORTING  (1.1. 8) I  ^ 


package  SYSTEM  COMMAND  INTERPRETER  (1.1.9)  is 

—  The  SYSTEM  COMMAND  INTERPRETER  provides  an  interactive* 
— conversational  interface  between  the  system  and  the 

— operators  terminal.  It  also  provides  a  batch  .processing 
--mode.  Services  provided  through  the  SYSTEM  COMMAND 

—  INTERPRETER  are? 

-user  login/logout 

-station  control  (user  ID*terminal  status) 

-system  task  status 
-system  I/O  status 
-logical  I/O  assignment 

-program  installation*deletion*  activation  and  control 
-system  log 

-system  log  activation* listing  and  termination 
-file  management  support 
-assembler  language  support 
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-Ads  language  support 

-libraries  support*  installation  and  deletion 
-utilities*  ext  editors?  sort/merge t system  generation 

package  ASSEMBLER  (1*1. 9.1)} 
package  ADA  LANGUAGE  <1. 1.9.2) 5 
package  LIBRARIES  (1.1, 9, 3)1 
package  EDITORS  (1. 1.9.4)) 
package  UTILITIES  (1. 1.9.5)) 
end  SYSTEM  COMMAND  INTERPRETER  (1.1.9)  ) 


package  MAINTENANCE  S  DIAGNOSTIC  UTILITIES  (1.1.10) f 
package  DESTRUCTIVE  OFFLINE  UTILITIES  (1.1.10.1)1 
package  NON-DESTRUCTIVE  ON  LINE  UTILITIES  (1.1.10.2)5 
end  MAINTENANCE  t  DIAGNOSTIC  UTILITIES  (1.1.10)5 
end  GENERAL  OPERATING  SYSTEM  (1.1)5 


package  RUNTIME  SUPPORT  SOFTWARE  (1.2)  is 
package  RUNTIME  OPERATING  SYSTEM  (1.2.1) 5 
package  RUNTIME  SYSTEM  LIBRARY  (1.2.2) 5 
package  MATHEMATICAL  LIBRARY  (1.2.3) 5 
package  CHARACTER  STRING  LIBRARY  (1.2.4) 5 
procedure  RUNTIME  ON-LINE  DEBUGGER  (1.2.5)  5 
end  RUNTIME  SUPPORT  SOFTWARE  (1.2)5 


package  RUNTIME  INITIALIZATION  (1.3)  is 
procedure  LOAD  RUNTIME  SUPPORT  SOFTWARE  (1.3.1) 5 
procedure  OPTION  LOAD  ONLINE  DEBUGGER  (1.3.2) 5 
procedure  LOADS  USER  APP  LIB  (1.3.3) 5 
procedure  OPTION  LOAD  SYSTEM  EXERCISOR  (1.3.4) 5 
procedure  LOAD  I/O  MSG  INTERPRETER  (1.3.5) 5 
procedure  OPTION  OPEN  TRANSACTION  MSG  LOG  (1.3.6) 5 
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procedure  LOAD  SITE  ADAPTATION  (1.3.7) i 
procedure  LOAD  TARGET  CONTROL  (1.3.8); 
procedure  LOAD  REMOTE  COMMUNICATION  (1.3.9); 
procedure  LOAD  RADAR  COMMMUNICATION  (1.3.10); 
end  RUNTIME  INITIALIZATION  (1.3); 


package  USER  APP  LIBRARY  (1.4)  is 
function  TRANSVERS  MERCATOR  (1.4.1); 
function  STEREGGRAPHIC  (1.4.2); 
function' SLANT  COORDINATE  (1.4.3); 
function  GEOGRAPHIC  (1.4.4); 
end  USER  APP  LIBRARY  (1.4)  »* 


package  I/O  MESSAGE  INTERPRETER  (1.5)  is 
procedure  MESSAGE  ROUTING  MANAGER  (1.5.1)  is 
procedure  INPUT  MESSAGES  (1.5. 1.1) ; 
procedure  OUTPUT  MESSAGES  (1. 5.1.2); 
end  MESSAGE  ROUTING  MANAGER  (1.5.1); 

procedure  DISPLAY  UPDATE  I/O  MANAGER  (1.5.2); 
end  I/O  MESSAGE  INTERPRETER  (1.5); 


package  RUNTIME  TERMINATION  (1.6)  is 
procedure  GENERATE  TERMINATION  MSG  TO  LOCAL/REMOTE  USERS 
(1.6.1); 

procedure  TERMINATE  RADAR  COMM  (1.6.2); 
procedure  TERMINATE  REMOTE  COMM  (1.6.3); 
procedure  TERMINATE  TARGET  CONTROL  (1.6.4); 
procedure  OPTIONALLY  CLOSE  TRANSACTION  MSG  LOG  (1.6.5); 
package  TERMINATION  OPTIONS  (1.6.6); 
end  RUNTIME  TERMINATION  (1.6); 
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package  RUNTIME  SYSTEM  EXERCISOR  (1,7)  is 
procedure  EXERCISOR  COMMAND  SUPERVISOR  (1,7,1)) 
procedure  USER  APPLICATION  LIBRARY  EXERCISOR  (1.7.2) 
procedure  I/O  MSS  INTERPRETER  EXERCISOR  (1.7.3) » 
procedure  SITE  ADAPTATION  EXERCISOR  (1.7,4)) 
procedure  TARGET  CONTROL  EXERCISOR  (1.7.5)) 
procedure  REMOTE  COMM  EXERCISOR  (1.7.6)) 
procedure  RADAR  COMM  EXERCISOR  (1.7.7)) 
end  RUNTIME  SYSTEM  EXERCISOR  (1.7) ) 
end  COMMAND  AND  CONTROL  (1.0)) 

♦  >is 

ZDCL-W-IVVERB*  unrecognized  command 
\>IS\ 

i'j 


♦  TW  TARGET. SDL 

package  TARGET_CONTRQi _ 2_0  is 

—  Target  control  is  one  of  four  packages  which  coapose  the 
— missle  minder  air  defense  A/N  TSQ-73  system.  The  target 
— control  package  processes  radar  report  data*  updates  track 
— data  based  on  recent  radar  reports  and  if  reouired? 

— automatically  initiates  new  tracks.  The  track  data  is  used 
— to  evaluate  the  threat  posed  by  a  track  to  defended  points 
— and  to  determine  the  fire  unit(s)  best  Qualified  to  engage  a 
— specific  hostile.  Upon  an  engagement  order?  target  control 
— is  responsible  for  monitoring  the  engagement  as  well  as 
— providing  friendly  track  protection.  During  system 
— initial ization  target  control  generates  the  algorithms 
— necessary  to  perform  the  air  defense  computations  which 
— contain  site  dependent  parameters.  Target  control  is  itself 
--composed  of  five  packages! 

o  Start-up-initial ization. 2.1 
o  T rat" ing_2_2 
o  Track.manager.2-3 
o  Counter_measure_processinS_2_4 
o  Target-engagement. 2-5 

package  START_UP_INITIALIZATI0N_2_l  is 

Upon  system  initialization?  all  tracking  and 
— target  engagement  algorithms  with  site  dependent 
— parameters  are  initialized.  In  addition  sector 
— definition  and  table  initialization  is  provided. 

procedure  INITIALIZE. TRACK. ALG0RITHMS_2_1_1 i 

—  Not  further  decomposed 

procedure  INITIALIZE_THREAT_EVALUATI0N_ALG0RITHMS_2_1_2 

--  Not  further  decomposed 
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procedure  INITIALIZE_WEAP0N-ASSIGNMENT_ALG0RITHMS_2_1_3 i 

—  Not  further  decomposed 

procedure  INITIALIZE_TRACK_TABLES_2_1_4? 

—  Not  further  decomposed 


procedure  SECTOR_DEFINITION_2_l_55 

—  Not  further  decomposed 


end  START_UP_INITIALIZATI0N_2_1  i 

package  TRACKING_2_2  is 

Tracking_2_2  processes  radar  reports  received  through 
— data_control_2_3_4  in  order  to  perform  identification  of  friend  or 
— foe  (iff/sif)?  correlate?  associate?  smooth?  and  predict  new 
— positions  for  existing  tracks?  automatically  initiate 
— new  tracks?  drop  tracks?  and  evaluate  track 
— Quality . 

package  IFF_SIF_2_2_1  is 

The  IFF_SIF  package  is  responsible  for  all 
— activities  which  are  reauired  to  identify  air  traffic  as 
--friendly  or  unfriendly. 

procedure  AUT0_BEC0N_INTERR0GATI0N_2_2_1_1  <  in 
NODE ?  in  out  POSi  out  RESULT)? 

Beacon  interrogation  shall  be  performed 
— automatically  whenever  the  category  of  a  track 
--is  altered. 


procedure  MANUAL_INTERR0GATI0N_2_2_1_2  <in 


M0DE1?  in  M0DE2 ?  in  out  POS?  out  RESULT ) ? 


—  Manual  interrogation  is  indirectly  reauested 
— by  the  operator  when  he  hooks  a  specific  auto  or  non-auto 
--track.  The  operator  may  specify  one  or  two  modes  for  use? 

— otherwise  the  current  system  modes  shall  be  used. 

procedure  VERIFY_IFF-C0DE-2_2_1_3  (in  MODE? 
in  out  POS?  out  OK)? 

Mode  1*2*3A*  and  C  codes  shall  be 
— verified  as  follows! 

o  If  a  radar  report  containing  a  mode  C  code  associates 
with  a  track*  the  code  shall  be  accepted  for  that  track, 
o  The  term  'certified*  applies  to  mode 
1*  mode  2*  and  mode  3A  codes.  Certification  shall  be 
accomplished  if  necessary*  whenever  automatic 
interrogation  is  performed.  This  certification  shall  be 
attempted  by  repeated  interrogation  until  one  of  two 
conditions  results! 

1.  Two  consecutive  matching  codes 

—  are  received 

2.  Three  consecutive  null  responses 

—  are  received  (null  condition). 

procedure  M0DE_4_INTERR0GATI0N_2_2_1_4  (in  out 
POS?  out  RESULT)? 

Mode_4_inter rogation  shall  be  reauested 
— directly  by  the  operator  and  the  response  shall  be  accepted 
— and  displayed. 

end? 

task  TARGET_REPORT_PROCESS I NG_2_2_2  is 

TARGET-REPORT-PROCESSING  is  responsible  for 
— performing  the  front  end  processing  on  ell  target  information 
—  received  by  TRACKING-2-0 .  Sources  for  this  data  are  local 
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— radar*  remote  radar*  remote  communication*  and  the  operator. 
— Local  and  remote  radar  reports  are  processed  in  such  a  . 

— manner  that  all  slant  coordinates  are  transformed  into 

—  rectangular  coordinates*  and  are  subseouentla  handed  to 
— the  TRACK. WHILE. SCAN-2-2.3  task.  The  reports  received  ba 
-~REM0TE_C0MMUNICATI0N_3_0  are  received  with  coordinate  data 

—  referenced  with  a  remote  sastem  coordinate  center  (SCO. 
~TARGET_REP0RT_PR0CESSING_2_2_2  processes  these  remote 

— reports  so  that  thea  all  are  referenced  with  the  local  SCC 
— and  have  their  coordinate  data  in  rectangular  form.  These 
— remote  reports  are  placed  in  the  track  storage  file  and 
— are  updated  with  remote  reports  received  on  succeeding  scans 
— The  reports  generated  ba  the  operator  are  considered  as 
— rate-aided-manual la-initiated-tracks  (RAMIT)  and  are 
— updated  manualla. 

entra  LOCAL _ RADAR  (  LOCAL _ RADAR-BUFFER  >  '* 

entra  REMOTE-RADAR (REMOTE .RADAR -BUFFER ) * 
entra  REMOTE-COMM(REMOTE-REPORT) * 
entra  OPERATOR(RAMIT) * 


end  T ARGET_REP0RT_PR0CESSING_2_2_2  i 

task  TRACK_WHILE_SCAN_2-2_3  is 

The  track  while  scan  task  is  the  central  activita 
— in  the  tracking  process.  It  is  the  repsonsibi 1 ita  of 
— the  track  while  scan  task  to  accept  the  target 
— report  information  generated  ba  the  local  and  remote 
—  radars  and  the  remote  track  information  received 
— ba  REMOTE-COMMUNICATION-3 . 0  and  to  match  the  most 
— recentla  received  information  with  the  historical 
— information  stored  for  each  track. 

entra  NEW _TGT -BUFFER  (TGT-REP-BUFF  )  * 

end  TRACK-WH I LE -SCAN -2-2-3  5 
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package  TRACK_WHILE_SCAN-UTILITIES_2_2_4 


is 


Track  while  scan  utilities  contains  the  routines 
— which  handle  the  automatic  initiation  and  dropping 
— of  tracks  to  and  front  the  track  storage  file  as  well 
— as  a  routine  which  estimates  the  reliability  of  the 
— positional  data  held  for  ana  given  track*  i*e.  track 
--Quality . 


procedure  AUTO.INITI ATI0N_NEW-TRACK_2-2_4_1 

(in  NON.ASSOC_TGT.REP  t  in  NON.CORREL_TGT.REP  )t 

The  automatic  initiation  capability  shall  apply 
— to  the  entire  radar  coverage  area  when  the  system 
— initiation  mode  is  AUTOMATIC*  When  the  initiation 
— mode  is  MANUAL  this  capability  shall  apply  only  within  5DM 
— of  non-auto  tracks* 

After  all  possible  target  report/track 
— associations  have  been  made  in  a  given  vicinity*  those 
— reports  that  have  failed  to  associate  with  any  existing 
— track  shall  be  used  to  generate  new  auto  tracks.  A  new 
— track  initiated  in  this  way  shall  be  placed  in  the 
— tenative  track  category.  For  the  purpose  of  the 
— association  count*  this  first  report  shall  count 
— as  an  association. 

Since  a  single  position  measurement  provides  no 
— velocity  estimate*  all  directions  and  speeds  are 
— eauiprobable .  However*  the  upper  and  lower  speed  limits 
— for  automatically  initiated  tracks  limit  the  area 
— witihn  which  subseouent  target  reports  must  fall 
— in  order  to  associate  with  these  initial  tenative 
— tracks . 

task  DROP-TRACK. 2. 2_4. 2  is 

A  RAMIT  track  shall  be  dropped  if  no  manual 
— update  action  is  taken  before  the  second  manual  update 
— warning  time  period  has  elapsed.  A  remote  non-auto  track 
— shall  be  dropped  if  it  has  received  no  remote  communication 
— message  update  for  60  seconds. 
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Provisional  and  established  tracks  shall  be 
— declared  to  be  in  poor  tracking  status  if  no  association 
— can  be  «tade  for  three  scans.  An  established  track  that 
— has  been  declared  in  poor  trackins  status  shall  be  chansed 
—to  provisional  with  a  radar  association  count  of  4.  An 
— operator  indication  shall  be  posted.  Provisional  tracks 
— shall  be  dropped  if  no  association  can  be  made  within  45 
— seconds  after  declaration  of  poor  trackins  status* 

— except  as  follows! 

o  Remote  auto  tracks  that  fail  to  associate  for 
three  scans  shall  be  switched  to  resote  non-auto, 
o  An*  track  that  is  locally  enSaSed  shall  not  be  dropped. 
In  this  case  the  track  shall  be  dead-reckoned  and  drop 
--  action  shall  be  attespted  in  each  succeedinS  scan. 

o  For  all  MBDL  desisnated  tracks*  if  the  tine  since  the 
last  update  is  eaual  to  or  sreater  than  45  seconds 
a  drop  indication  is  warranted  and  posted. 

entry  TRK-DATA  <  in  NON_ASSOC_TRACKJ 

in  NON-CORREI _ TRACK) * 

end  DR0P_TRACK»2_2_4_2  } 

task  DETERMINE_TRACK_QUALITY_2_2_4_3  is 

Local  track  Quality  is  an  assigned  value  based 
— upon  the  degree  of  estimated  reliability  of  the 
— positional  data.  The  assigned  value  for  real-tine 
— tracks  shall  be  limited  to  range  of  1  through  7. 

— A  track  Quality  of  0  shall  indicate  a  non-real 
— tine  track. 

The  track  Quality  of  local  auto  tracks  used  for 
— ATDL-1  and  TADIL-B  reporting  responsibility  shall  be! 
o  Initially  reported  as  4  when  a  track  becomes 
provisional. 

o  Incremented  by  one  after  two  successive 
associations . 

o  Decremented  by  one  after  two  successive 
misses. 

—  The  track  Quality  of  local  non-auto  tracks 
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— (remit)  used  for  ATDL-1  and  TADIL-B  reporting 
— responsibility  shall  be* 

o  Initially  reported  as  4  when  track  is 
Manually  initiated. 

o  Incremented  by  one  as  a  result  of  a  Manual 
update  action. 

o  Decremented  by  one  when  two  successive 
scans  have  occurred  without  a  manual 
update  action. 

The  track  ouality  of  pop-up  tracks  used  for 
— ATDL-1  and  TADIL-B  reporting  responsibility 
— shall  bet 

o  Initially  reported  as  4  when  a  pop-up 
track  is  declared. 

o  Decremented  by  one  when  two  successive 
scans  have  occurred  without  any  fire  unit 
update. 


entry  TRK-DAT A  <  in  ASSOC-DATA)  » 

end  DETERMINE-TRACK-QUALITY-2-2-4-3  i 

end  TRACK_UHILE_SCAN_UTILITIES_2_2_4  ; 

end  TRACKING_2_2  i 

package  TRACK_MANAGER_2_3  is 

The  track  manager  provides  the  capability  necessary 
— to  receive  »  send  and  route  all  intra-system  messages 

— pertinent  to  TARGET_CONTROI _ 2_0.  In  addition  the 

— TRACK-MANAGER  is  responsible  for  the  maintenance 
— of  all  tables  unioue  to  the  TARGET-CONTROI — 2_0 
— activity . 

procedure  TRACK_UPDATE_2_3_1 t 

—  Not  further  decomposed 
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procedure  MANAGE_TABLES_2_3_2 » 


—  Not  further  decomposed 


procedure  DETERMINE_TRACK_STATUS_2_3_3 » 

—  Not  further  decomposewd 


procedure  DATA_C0NTR0L_2_3_4 f 

—  Not  further  decomposed 


procedure  0PERAT0R_SWITCH_ACTI0NS_2-3_5 $ 

—  Not  further  decomposed 


end  TRACK-MANAGER-2.. 3  t 

package  C0UNTER_MEASURE_PR0CESSING_2_4  is 

COUNTER-MEASURE-PROCESSING- 2-4  provides  all 
— activities  necessary  to  provide  effective 
— identification  and  control  for  air  traffic 
— which  attempt  to  avoid  detection  through  use 
— of  Jamming  or  chaff  technioues. 

procedure  JAM_STR0BE_PR0CESSING_2_4-1 i 

—  Not  further  decomposed 


procedure  CHAFF-PROCESSING-2-4-2 i 

—  Not  further  decomposed 
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end  COUNTER-MEASURE-PROCESSING-2-4  i 


package  TARGET -ENGAGEMENT _2_5  is 

The  objective  of  TARGET_EN6AGEMENT_2_5  is  to 
— evaluate  the  threat  posed  to  defended  points  by 
— unknown  and  hostile  air  traffic*  After  calculation 
— of  the  threat  posed  by  each  track*  the  fire  unit(s) 

— best  Qualified  to  engage  that  particular  track  are 
— determined*  Upon  an  engagement  order* 

— TARGET_EN6AGEMENT_2_5  is  responsible  for  monitoring  all 
— engagements « 

procedure  EVALUATE_THREAT_2_5_1  i 

EVALUATE-THREAT-2-5-1  obtains  track  information 
— for  each  track  and  evaluates  the  threat  posed  by  that 
— track  to  each  defended  point*  The  threat  posed  by 
— each  track  for  each  defended  point  shall 
— be  evaluated  once  for  each  scan* 

procedure  E V ALU ATE-UEAPON- ASSIGNMENT -SCORE-2 -5-2* 

E V AL U ATE -WEAPON- ASS I GNME NT -SCORE-2 _ 5 _2  computes 
— a  value  which  is  used  by  the  WEAP0N_ASSIGNMENT_2_5_3 
— activity  to  assign  a  target  to  the  appropriate  fire 
— unit(s) . 

procedure  WEAPON-ASSIGNMENT-2-5-3 > 

WEAPON. ASSIGNMENT -2 -5-3  automatically  assigns  the 
— fire  unit(s)  best  Qualified  to  engage  hostile  air 
— tracks*  It  also  performs  bookeeping  operations  which  a 
— necessary  to  maintain  stockpile  balancing  as  well  as 
— distinguish  between  weapons  tight  and  weapons  free* 

— In  the  weapons  tight  mode  assignment  of  unknown  tracks 
— made  be  accomplished  by  manual  operation  only* 

procedure  M0NIT0R_ENGAGEMENT_2_5_4  i 

MON I TOR-ENGAGEMENT _2_5 _4  shll  provide  friendly 
— protection  by  monitoring  the  engagement  status  of 
— friendly  and  unknown  tracks.  In  addition*  it  shall 


— Monitor  engaged  tracks  relative  to  safe  corridors. 

— Hold  fire  alerts  shall  be  issued  to 
— REM0TE_C0HMUNICATI0N_3.0  if  engaged  targets  are 
— within  safe  corridors. 

end  TARGET_ENGAGEMENT_2_5  i 

end  TARGET_C0NTROL_2_O  i 

package  body  TARGET-CONTROI _ 2_0  is 

package  body  START_UP_INITIALIZATI0N_2_1  is 

Upon  system  initialization!  all  tracking  and 
— target  engagement  algorithms  with  site  dependent 
— parameters  are  initialized.  In  addition  sector 
— definition  and  table  initialization  is  provided. 

procedure  INITIALIZE_TRACK_ALG0RITHMS_2-1-1  is 

—  Not  further  decomposed 

end  INITI ALIZE_TRACK_ALG0RITHMS_2-1-1  » 

procedure  INITIALIZE_THREAT_EVALUATI0N_ALG0RITHMS_2_1_2  is 

—  Not  further  decomposed 

end  INITIALIZE_THREAT_EVALUATI0N_ALG0RITHMS_2_1_2  t 

procedure  INITIALIZE_WEAP0N_ASSIGNMENT.ALG0RITHMS_2_i_3  is 

—  Not  further  decopmosed 

end  INITIALIZE.UEAP0N-ASSIGNNENT_ALG0RITHNS_2_l-3 i 

procedure  INITIALIZE_TRACK_TABLES_2_l-4  is 
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Not  further  decomposed 


end  INITI ALIZE_TRACK.TA6LES_2.1_4  i 

procedure  SECT0R_DEFINITI0N_2_1_5  is 

—  Not  further  decomposed 

end  SECT0R_DEFINITI0N_2_1_5  I 

end  START_UP_INITI ALIZATI0N_2_1  i 

package  body  TRACKING-2-2  is 

package  body  IFF_SIF_2_2_1  is 

The  IFF_SIF  package  is  responsible  for  all 
—activities  which  are  reoui^ed  to  identify  air  traffic  as 
— friendly  or  unfriendly. 

procedure  INTERR0GATE_BEAC0N_2_2_1_5 
(in  MODE,  in  out  POSf  out  RESULT)  is 

Interrogate  beacon  is  the  activity  which 
— handles  the  actual  calling  of  the  IFF-SIF  beacon  component 
— of  the  radar  hardware.  The  interrogation  mode  currently  in 
— effect  and  the  positionof  the  air  traffic  in  Question  are 
— accepted  as  input  and  a  valid  or  invalid  response  is 
— received  from  the  beacon  and  subseauently  returned  to 
— the  calling  activity. 

begin 

SEND_INQUIRY_TO_AIRCRAFT (MODE) 5 
RECEIVE. AIRCRAFT-RESPONSE (AIRCRAFT -RESPONSE )  . 
if  AIRCRAFT-RESPONSE  =  MODE  then 
RESULT  *  TRUE . 
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end  iff 


end  INTERR0GATE_BEAC0N_2_2-1_5 


procedure  AUT0_BEC0N_INTERR0GATI0N_2-2_1_1  (  in 
MODE?  in  out  POS)  out  RESULT)  is 

Beacon  interrogation  shall  be  performed 
— automatically  whenever  the  category  of  a  track 
— is  altered* 

begin 

INTERROGATE-BEACON-2-2-1-5  < MODE t POS f RESULT ) * 

end  AUTO-BEACON_ INTERROGATION. 2.2 -1-5 ) 


procedure  MANUAL-INTERROGATION-2-2-1-2  (in 

M0DE1 )  in  M0DE2 )  in  out  POS)  out  RESULT)  is 

Manual  interrogation  is  indirectly  reauested 
— by  the  operator  when  he  hooks  a  specific  auto  or  non-auto 
— track.  The  operator  may  specify  one  or  two  modes  for  user 
— otherwise  the  current  system  modes  shall  be  used. 

begin 

INTERR0GATE-BEAC0N.2-2-1-5  < M0DE1 f POS f RESULT ) ) 
if  M0DE2  SPECIFIED  then 

INTERR0GATE_BEAC0N(M0DE2  f POS f RESULT  >  ) 
end  if? 

end  MANUAL- INTERROGATION-2 _2_1 _2  ) 

procedure  VERIFY-IFF-CODE-2-2-1-3  (in  MODE) 
in  out  POS)  out  OK)  is 

Mode  lf2f3Af  and  C  codes  shall  be 
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— verified  as  follows 


o  If  3  radar  report  containing  a  node  C  code  associates 
with  a  track?  the  code  shall  be  accepted  for  that  track, 
o  The  tern  •certified*  applies  to  node 
1?  node  2?  and  node  3A  codes.  Certification  shall  be 
acconplished  if  necessary?  whenever  automatic 
interrogation  is  performed.  This  certification  shall  be 
attenpted  by  repeated  interrogation  until  one  of  two 
conditions  results* 

1.  Two  consecutive  matching  codes 

are  received 

2.  Three  consecutive  null  responses 

are  received  (null  condition)*. 


begin 


if  MODE  =  C  then 

ok  :=  true; 

else 

loop 

INTERR0GATE-BEAC0N-2-2-1-5 ( MODE ?POS? RESULT ) ? 
EVALUATE  MATCHING  CODES; 

EVALUATE  NON-MATCHING  CODES; 
exit  when  CONSEC-MATCH  =  2  or 
NON-CONSEC-MATCH  =  3; 
end  loop; 


end  VERIFY- 1 FF_C0DE_2_2_ 1-3 f 


procedure  M0BE_4_INTERR0GATI0N_2_2_1_4  (in  out 
POS;  out  RESULT)  is 

Mode-4-interrogation  shall  be  rectuested 
— directly  by  the  operator  and  the  response  shall  be  accepted 
--and  displayed . 


begin 


INTERR0GATE-BEAC0N.2-2-1-5  ( MODE ? POS ? RESULT ) ; 
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DISPLAY-PPI (RESULT) » 


end  H0DE_4_INTERR0GATI0N_2_2-l-4  i 

end  IFF_SIF_2_2_1  i 

task  bods  TARGET-REP0RT-PR0CESSING-2-2-2  is 

— not  further  decomposed 

end  TARGET-REPORT-PROCESS I NG_2_2_ 2  } 


task  bods  TRACK_WHILE_SCAN_2-2_3  is 

package  C0RRELATI0N-ACTI0NS.2. 2-3-1  is 

Each  target  report  position  shall  be  compared  with 
— all  tracks  in  it's  vicinits  to  determine  if  the  report  is 
— close  enough  to  correlate*  each  report  mas  correlate  with 
— more  than  one  track. 

procedure  C0MPl)TE_DEVIAT10N_VECT0R_2_2_3-l_l 
(in  TGT_REP._POS i  in  TRK-POSJ  out  DEV-VEC  >i 

For  all  categories  of  tracks  the  ouantits  of 
— interest  is  the  deviation  vector  between  the  track  predicted 
— position  and  the  target  report  position. 


procedure  INNER-GATE-C0RRELATI0N_2_2-3_1_2 

(in  TGT-REP-NO?  in  TRK.REC.NOi  in  DEV-VECf  out  IG-CORR  )i 

For  maneuvering  tracks  and  non-manuever ins 
— tracks  three  tspes  of  inner  gates  shall  be  used! 
o  For  non-maneuvering  tracks 
o  distance  Sate  check 
o  range  and  azimuth  error  check 
o  For  maneuvering  tracks 
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o  maneuver  recovery  Sate  check 


procedure  INNER_GATE_C0RRELATI0N_2_2_3_1_2 

(in  TGT_REP_NO »  in  TRK_REC_NO»  in  DEV-VEC.  out  IG_CORR  >5 

The  outer  dates  shall  be  oriented  parallel  to 
— and  normal  with  each  track's  velocity  vector.  The  outer  date 
— correlation  tests  shall  be  performed  by  decomposind  the 
— deviation  vector  into  two  orthodonal  components. 

—  o  Ud  in  a  direction  perpendicular  to  the 
track's  headind 

o  Ud  in  the  fore  and  aft  direction. 

Irrespective  of  the  values  diven  by  the 
— formulas  shown  in  the  packade  body  an  upper  bound  of  10  DM 
— and  a  lower  bound  of  1  DM  shall  be  placed  on  all  outer  date 
— values.  If  all  tests  are  passed,  the  tardet  report 
— correlates  with  the  track  in  the  outer  date.  If  any  test 
— fails  the  tardet  report  fails  to  correlate  with  the  track. 

procedure  0UTER_GATE_C0RRELATI0N_2_2_3_1_3  (in 

TGT_REP_N0 »  in  TRK_N0»  in  DEV-VEC*.  out  OG.CORR  )i 

'he  outer  dates  shall  be  oriented  parallel  to 
— and  normal  with  each  track's  velocity  vector.  The  outer  date 
— correlation  tests  shall  be  performed  by  decomposind  the 
— deviation  vector  into  two  orthodonal  components. 

o  Ud  in  a  direction  perpendicular  to  the 
track's  headind 

o  Ud  in  the  fore  and  aft  direction. 

Irrespective  of  the  values  diven  by  the 
— formulas  shown  in  the  packade  body  an  upper  bound  of  10  DM 
— and  a  lower  bound  of  1  DM  shall  be  placed  on  all  outer  date 
— values.  If  all  tests  are  passed,  the  tardet  report 
--correlates  with  the  track  in  the  outer  date.  If  any  test 
--fails  the  tardet  report  fails  to  correlate  with  the  track. 
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procedure  N0N_AUT0_BEAC0N_C0RRELATI0N_2_2_3_1_4 


I, 

P 


r 

[. 

t 


(in  TGT-IFF *  in  TRK.IFF*  out 
NON-AUTO-BN-CORR ) * 

If  the  absolute  miss  distance  on  Srid  system 
— coordinates  is  greater  than  5  DM*  no  correlation 
— may  take  place*  If  the  report  contains  no 
— IFF/SIF  data*  no  correlation  may  take  place* 

— Otherwise*  the  report  is  correlated  and  the 
--correlation  score  is  set  to  1* 


procedure  ALTITUDE-GATE_C0RRELATI0N_2_2_3_1_5 
(in  TGE_REP_ALT *  in  TRK-ALT »  out 
ALT_GATE_CORR ) * 

If  a  tarSet  report  correlates  with  a  track  for 
— either  the  inner  or  the  outer  Sate*  the 
— possibility  of  correlation  in  altitude  shall  be 
— examined.  Each  track  has  an  altitude  estimate 
— associated  with  it  which  may  be  derived  from  3D 
— measurement  from  mode  C  beacon  responses  or 
— from  operator  inputs.  If  there  are  no  altitude 
— data*  the  track  shall  be  assiSned  a  default 
— altitude  of  20*000  feet.  If  the  correlatinS 
— repcrt  contains  an  altitude  measurement*  either 
— from  a  3D  radar  or  mode  C*  this  altitude  shall 
— be  compared  to  the  track  altitude. 


procedure  C0RRELATI0N_SC0RE_2_2.3_1_6 

(  in  TGT_REP_N0 *  in  TRK_N0*  in  P0S-C0RK*  in  IFF.CORR 
in  ALT.CORR*  out  C0RR_SC0RE>? 

—  Burins  the  correlation  process  for  each  track* 

— a  record  shall  be  kept  of  the  tarset  reports 
— that  correlate  with  that  auto-track*  up  to  a 
— maximum  of  three  reports.  Each  report  that  has  a 
— position  correlation  shall  be  Siven  a 


— correlation  score  with  respect  to  the  track. 

— If  more  than  three  reports  correlate*  the  three 
— with  the  highest  correlation  scores  shall  be 
— retained  for  possible  use  in  the  association 
— process.  In  addition*  a  record  shall  be 
— maintained  of  up  to  three  correlating  tracks  per 
— target  report*  for  use  in  the  association 
— process.  There  are  three  separate  correlation 
— scores  that  are  used  to  determine  the  final 
— correlation  score* 

o  Position  correlation 
o  Altitude  correlation 
o  IFF  correlation. 

end  C0RRELATI0N_ACTI0NS_2_2_3_1  '* 

package  body  C0RRELATI0N_ACTI0NS_2_2_3_1  is 

procedure  C0MPUTE_DEVIATI0N_VECT0R_2_2-.3-l_l 
(in  TGT_REP_POS *  in  TRK-PQSi  out  DEV_VEC  )  is 

For  all  categories  of  tracks  the  Quantity  of 
— interest  is  the  deviation  vector  between  the  track  predicted 
— position  an-"!  the  target  report  position. 

begin 

COMPUTE  SCALAR  POSITION  DIFFERENCES* 

COMPUTE  DEVIATION  VECTOR  LENGTH* 

end  COMPUTE-DEVI ATI0N_VECT0R_2_2_3_  1  _  1  ? 

procedure  INNER_GATE_CORRELAT I  ON, :  :  ?  : 

(in  TGT_REP_N0  5  in  TRK_  RE  C -  NO  «  i '  :  t 

For  maneuvering  *rir»»  *  «... 

--tracks  three  tyre*  of  *>,  * 
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o  For  non-aaneuverind  tracks 
o  distance  date  check 


o  rande  and  aziauth  error  check 
o  For  aaneuverind  tracks 

o  aaneuver  recovery  date  check 

IG-CORR  t  BOOLEAN  J*  FALSE * 

bedin 

if  NON-MANVR  then 

CHECK  DISTANCE-GATE-CORRI 
if  DISTANCE-GATE-CORR  then 
IG-CORR  J=  TRUE * 
else 

CHECK  RANGE-AND-AZIMUTH-ERROR-CORR* 
if  RANGE-AND-AZIMUTH-ERROR-CORR  then 
IG-CORR  :«  TRUE! 
end  if* 
end  iff 
else 

CHECK  R-GATE-CORR* 
if  R-GATE-CORR  then 
IG-CORR  t«  TRUE* 
end  if* 
end  if? 

end  INNER-GATE-C0RRELATI0N-2-2.3-1-2* 

procedure  0UTER-GATE_C0RRELATI0N_2_2-3-l_3  (in 

Gr- 

TGT-REP-NOI  in  TRK-NO*  in  DEV-VEC*  out  OG-CORR  >  is 

The  outer  dates  shall  be  oriented  parallel  to 
— and  noraal  with  each  track's  velocity  vector*  The  outer  date 
—correlation  tests  shall  be  perforaed  by  decoaposind  the 
— deviation  vector  into  two  orthodonal  coaponents* 
o  Ud  in  a  direction  perpendicular  to  the 
track's  headind 

o  Wd  in  the  fore  and  aft  direction* 

Irrespective  of  the  values  diven  by  the 


k..W 


—formulas  shown  in  the  package  bods  sn  upper  bound  of  10  DM 
— end  a  lower  bound  of  1  DM  shall  be  placed  on  all  outer  sate 
— values*  If  all  tests  are  passed*  the  target  report 
— correlates  with  the  track  in  the  outer  Sate*  If  anw  test 
— fails  the  target  report  fails  to  correlate  with  the  track* 

0G-C0RR  5  BOOLEAN  J=  FALSE* 

begin 

COMPUTE  AFT-GATES* 

COMPUTE  LATERAL-GATES* 

CHECK  LATERAL-GATE-CORR* 
if  LATERAL-GATE-CORR  then 
CHECK  AFT-GATE-CORR* 
if  AFT-GATE-CORR  then 
OG-CORR  }•  TRUE* 
end  if* 
end  if* 

end  0UTER-GATE-C0RRELATI0N-2-2-3-1-3* 

procedure  N0N_AUT0_BEAC0N_C0RRELATI0N_2_2_3_1_4 
(in  TGT-IFF *  in  TRK-IFF *  out 
NON-AUTO.BN-CORR) * 

If  the  absolute  eiss  distance  on  grid  swstea 
— coordinates  is  greater  than  5  DM*  no  correlation 
— taw  take  place*  If  the  reptort  contains  no 
— IFF/SIF  data*  no  correlation  gaw  take  place* 

—Otherwise*  the  report  is  correlated  and -the 
— correlation  score  is  set  to  1* 


S'/' 


fi'Z* 
»  ' 


—  Documentation  provided  does  not  support  an 

—  accurate  description*  hence  none  is  offered. 

end  N0N-AUT0-BEAC0N-C0RRELATI0N-2-2-3-1-4  * 

procedure  ALTITUDE-GATE-C0RRELATI0N-2-2.3-1.5 
(in  TGE-REP-ALT*  in  TRK-ALT *  out 
ALT-GATE-CORR)  is 
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If  a  target  report  correlates  with  a  track,  for 
— either  the  inner  or  the  outer  gate*  the 
— possibility  of  correlation  in  altitude  shall  be 
— examined*  Each  track  has  an  altitude  estimate 
— associated  with  it  which  saw  be  derived  from  3D 
— measurements*  from  mode  C  beacon  responses  or 
— from  operator  inputs*  If  there  are  no  altitude 
— data*  the  track  shall  be  assigned  a  default 
— altitude  of  20*000  feet*  If  the  correlating 
— report  contains  an  altitude  measurement*  either 
— from  a  3D  radar  or  mode  C*  this  altitude  shall 
— be  compared  to  the  track  altitude* 


ALT-GATE-CORR  i  BOOLEAN  }=  FALSE) 


begin 


if  I6-C0RR  or  QG-CORR  then 

if  TRK_ALT  not  ASSIGNED  then 
TRK-ALT  J*  20.000) 

TRK-ALT-MAX  )«  25-000) 

TRK-ALT-MIN  !■  15-000) 
end  if) 

if  TGT-ALT  >■  TRK-ALT-MAX  and  <«  TRK-ALT-MIN 
then  ALT-GATE-C0RR  t>  TRUE ) 
end  if) 
end  if) 


end  ALTITUDE-GATE-C0RRELATI0N-2.2-3-1-5) 


procedure  C0RRELATI0N-SC0RE-2.2-3-1-6 

(  in  TGT-REP-N0)  in  TRK-N0)  in  P0S-C0RR)  in  IFF-C0RR) 
in  ALT-CORR)  out  CQRR-8C0RE) ) 

During  the  correlation  process  for  each  track* 

— a  record  shall  be  kept  of  the  target  reports 
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— that  correlate  with  that  auto-track*  up  to  a 


— eaxieua  of  three  reports*  Each  report  that  has  a 
— position  correlation  shall  be  given  a 
— correlation  score  with  respect  to  the  track* 

— If  sore  than  three  reports  correlate?  the  three 
— with  the  highest  correlation  scores  shall  be 
— retained  for  possible  use  in  the  association 
— process*  The  final  correlation  score?  between  3 
— and  15?  as  derived  froe  the  following  criteria? 
— shall  be  used  as  a  Measure  of  the  oualitw  of 
— correlation*  In  addition?  a  record  shall  be 
— Maintained  of  up  to  three  correlating  tracks  per 
— target  report?  for  use  in  the  association 
— process*  There  are  three  separate  correlation 
— scores  that  are  used  to  detereine  the  final 
— correlation  score* 

o  Position  correlation 
o  Altitude  correlation 
--  o  IFF  correlation* 


begin 

COMPUTE  POSITION-SCORE t 
COMPUTE  ALTITUDE-SCORE  f 
COMPUTE  IFF-SCORE? 

COMPUTE  FINAL-CORR-SCORE  S 
LOAD_PAIRING_BUFFER t 
end  CORRELATION-SCORE-2-2-3-1-6; 
end  C0RRELATI0N-ACTI0NS-2-2-3-1  ; 


procedure  ASSOCIATION-2-2.3-2  ; 

In  the  association  process?  each  track  shall 
— be  exaeined  to  see  which  of  several  correlating  target 
— reports  should  be  associated  with  the  track* 

— After  all  tracks  and  target  reports  in  a  given  area 
— have  been  coopered  for  correlation?  the  best 
— target  report  for  each  trsck  shall  be  selected* 

—Auto  track  categories  shall  be  treated 
— separately  and  in  the  following  priority  order; 


o  Established 


o  Provisional 
o  Tenative. 

The  track-to-report  pairings  noted  under 
— correlation  shall  be  used  in  conjunction  with  the 
— final  correlation  scores  to  select  the  eost  likelv 
— report-track  associations* 

—  If  a  target  report  associates  with  a  track  in 
— one  category*  it  shall  becoae  inelisble  for 
— processing  in  anw  lower  prioritv  category.  The 
—association  process  shall  resolve  all  conflicting 
— correlations  bw  exaaining  the  correlation  scores* 

— The  report  with  the  highest  score  shall 
—associate  with  the  track*  If  the  highest  two  or 
— three  scores  are  the  saaei  the  pairing  with  the  ainiaua 
— deviation  distance  shall  be  associated* 

For  each  track*  count  shall  be  kept  of  the  nuaber  of 
— tiaes  the  track  has  associated  with  reports*  This 
—association  count  shall  a  aaxiaua  value  of  15* 
Association  will  operate  on  a  buffer  which 
— has  been  loaded  bw  correlation*  There  will  be  one 
— buffer  per  sector*  Each  buffer  contains  a  table 
— that  links  a  track  record  with  ail  possible 
— correlating  target  reports  and  correlation  scores 
—and  deviation  vector  values* 

begin 

SORT-PAIRINGS-BY-TRACK-CATEGORY  ) 
for  I  in  TRACK. CATEGORY  loop 
COHPARE-CORRELAT I ON-SCORES  ) 
for  K  in  NO-TRKS-IN-CATEGORY  loop 
MERGE-CONDITION-TEST  ) 

IFF-EMERGENCY-TEST  ) 

UPDATE-ASSOCIATION. COUNT  ) 
end  loop) 
end  loop) 

AUTO-INITIATION-NEU.TRACK-2-2-4-1 
(NON-ASSOC-TGT-REP  )) 

end  A880CIATI0N.2-2-3-2  ) 
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procedure  SM00THING_2_2_3_3  (in  TGT-REP-P08I 
in  TRK-POSI  in  TRK-VEL*  in 
LAST-SMOOTH-TIMEI  out  SMOOTH-POSt  out 
SMOOTH- VELf  out  SMOOTH- VEL> I 

The  smoothing  process  shell  take  place  after 
— a  target  has  been  associated  with  a  track 
— and  shall  involve  estimating  the  current 
— track  position  /  velocitw  based  upon  previous 
— track  position?  velocitw*  the  time  of  last  smoothing* 
— and  the  new  measurement  information*  Because  the 
— predicted  position  represents  the  recent  historw  of 
— the  track*  and  the  target  report  position  represents 
— the  best  choice  of  the  latest  observations*  the 
— smoothing  process  shall  emplov  a  weighted  average 
--of  the  two  positions  and  of  the  previous  and 
— indicated  velocities*  The  weighting  factors  are 
— called  smoothing  constants* 

Several  sets  of  smoothing  constants  shall 
— be  used  to  accomodate  a  range  of  maneuver 
--performance. 

— The  smoothing  constants  will  be  governed  bw  the 
— following  rules! 

—  o  for  a  non-maneuvering  track*  the 
heaviest  smoothing  shall  be  used* 
o  for  a  maneuvering  track*  the  smoothing 
index  shall  become  one  step  heavier  for 
recoverw  gate  association  and  one  step 
lighter  for  each  outer  gate  association. 

If  no  association  processing  was  performed 
—for  a  track*  that  track  shall  not  be 
— smoothed  in  that  scan* 

The  smoothing  procedure  accepts  the  track 
—to  report  pairing  table  generated  bw  association* 

—as  new  input  pairings* 

0 

begin 
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if  ASSOC  then 


OBTAIN  SMOOTHING-CONSTANTS) 

SMOOTH  POSITION) 

SMOOTH  VELOCITY) 

SMOOTH  ALTITUDE) 
end  if) 

end  SMOOTHING-2.2-3-3  ) 

procedure  PREDICTION-2-2-3.4  (in  SMOOTH-POS)  in 
SMOOTH-VEL)  out  PRED-POS)) 

Once  per  radar  scan*  each  track  shall  be 
— dead-reckoned  forward  to  the  point  where  it 
--should  next  be  seen  bw  the  radar*  This  process 
— shall  follow  the  correlation*  association* 

— and  smoothing  processes* 

Prediction  accepts  a  track-record 
— f roe  saoothins  or  froa  the  file  of 
— track  records  that  did  not  associate  with  anw 
— target  report* 


bed  in 


COMPUTE  ASSOC-PREDICTED-POSITION) 
COMPUTE  NQN-A8S0C-PREDICTED-P0SITI0N) 

end  PREDICTION-2-2-3-4) 

brain  — bodu  of  TRACK  WHILE  SCAN 

accept  NEW-TGT-BUFFER  <  TGT-REP-BUFF  >  do 
OBTAIN  SECTORIZED  TRACK  DATA) 

CORRELATE) 

ASSOCIATE) 

SMOOTH) 

PREDICT) 

for  NON-ASSOC  and  NON-CORREL-TGT-REP  loor 
AUTQ-INITIATION-NEW_TRACK_2-2_4_l ) 


end  loop) 


for  NON-ASSOC  and  NON-CORREL-TGT.REP  loop 
DR0P_TRCK_2_2_4_2 ) 
end  loop) 
end  accept) 

end  TRACK_WHILE_SCAN_2_2_3  ) 

Package  boda  TRACK_WHILE_SCAN_UTILITIES_2_2_4  is 

—  Track  while  scan  utilities  contains  the  routines 
—which  handle  the  autoeatic  initiation  and  dropping 
— of  tracks  to  and  fro*  the  track  storage  file  as  well 
— as  a  routine  which  estimates  the  reliabilita  of  the 
— positional  data  held  for  ana  given  track*  i.e.  track 
— Quality* 

Procedure  AUT0_INITIATI0N_NEW,TRACK_2_2-4_1 
(  NON_ASSOC_TGT_REP  J  TGT-REP  )  is 

The  autonatic  initiation  capabilita  shall  appla 
— to  the  entire  radar  coverage  area  when  the  saste* 

— initiation  node  is  AUTOMATIC*  When  the  initiation 
— node  is  MANUAL  this  capabilita  shall  appla  onla  within  SDH 
— of  non-auto  tracks* 

After  all  possible  target  report/track 
— associations  have  been  *ade  in  a  given  vicinitw*  those 
— reports  that  have  failed  to  associate  with  ana  existing 
— track  shall  be  used  to  generate  new  auto  tracks*  A  new 
— track  initiated  in  this  waa  shall  be  placed  in  the 
— tenative  track  categora*  For  the  purpose  of  the 
— association  count*  this  first  report  shall  count 
— as  an  association* 

Since  a  single  position  measurement  provides  no 
— velocita  estimate*  all  directions  and  speeds  are 
— eouiprobable*  However*  the  upper  and  lower  speed  limits 
— for  autoaaticalla  initiated  tracks  limit  the  ares 
— witihn  which  subseeuent  target  reports  must  fall 
— in  order  to  associate  with  these  initial  tenative 
— tracks* 

— not  further  decomposed 


D-40 


•nd  AUT0-INITIATI0N_NEU-TRACK-2_2-4_l  I 


task  body  DROP-TRACK-2-2-4-2  is 

A  RAMIT  track  shall  ba  dropped  if  no  aanual 
--update  action  is  taken  before  the  second  aanual  update 
— warning  tiae  period  has  elapsed*  A  reaote  non-auto  track  - 
— shall  be  dropped  if  it  has  received  no  reaote  coaaunication 
— aessage  update  for  60  seconds* 

Provisional  and  established  tracks  shall  be 
— declared  to  be  in  poor  tracking  status  if  no  association 
— can  be  aade  for  three  scans*  An  established  track  that 
— has  been  declared  in  poor  tracking  status  shall  be  changed 
— to  provisional  with  a  radar  association  count  of  4*  An 
— operator  indication  shall  be  posted*  Provisional  tracks 
— shall  be  dropped  if  no  association  can  be  aade  within  45 
— seconds  after  declaration  of  poor  tracking  status* 

— except  as  follows* 

o  Reaote  auto  tracks  that  fail  to  associate  for 
three  scans  shall  be  switched  to  reaote  non-auto, 
o  Any  track  that  is  locally  engaged  shall  not  be  dropped* 
In  this  case  the  track  shall  be  dead-reckoned  and  drop 
action  shall  be  atteapterd  in  each  succeeding  scan* 
o  For  all  HBDL  designated  tracks*  if  the  tiae  since  the 
last  update  is  eoual  to  or  greater  than  45  seconds 
a  drop  indication  is  warranted  and  posted* 

—  n<  t  further  decoaposed 

end  DROP-TRACK-2-2-4-2  * 

task  body  DETERHINE_TRACK_QUALITY-2_2_4_3  is 

Local  track  Quality  is  an  assigned  value  based 
— upon  the  degree  of  estiaated  reliability  of  the 
— positional  data.  The  assigned  value  for  real-tiae 
— tracks  shall  be  liaited  to  range  of  1  through  7* 

— A  track  Quality  of  0  shall  indicate  a  non-real 
— tiae  track* 

—  The  track  Quality  of  local  auto  tracks  used  for 

— ATDL-1  and  TADIL-B  reporting  responsibility  shall  bet 

—  o  Initially  reported  as  4  when  a  track  becoaes 
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—  provisional* 

o  Incremented  by  one  after  two  successive 

—  associations* 

—  o  Decremented  by  one  after  two  successive 

misses* 

The  track  oualita  of  local  non-auto  tracks 
— (remit)  used  for  ATDL-1  and  TADIL-B  reporting 
— responsibility  shall  be* 

o  Initially  reported  as  4  when  track  is 

—  manually  initiated* 

o  Incremented  ba  one  as  a  result  of  a  manual 

—  update  action* 

—  o  Decremented  ba  one  when  two  successive 

—  scans  have  occurred  without  a  manual 

—  update  action* 

The  track  Quality  of  pop-up  tracks  used  for 
— ATDL-1  and  TADIL-B  reporting  responsibility 
— shall  be* 

o  Initially  reported  as  4  when  a  pop-up 
track  is  declared* 

—  o  Decremented  bv  one  when  two  successive 

—  scans  have  occurred  without  any  fire  unit 
update. 

—  not  further  decopmosed 

end  DETERMINE_TRACK_QUALITY_2_2_4_3  f 

end  TRACK.UHILE-SCAN_UTILITIES_2.2-4  i 

end  TRACKING-2-2  t 

package  body  TRACK-HANAGER-2.3  is 

The  track  manager  provides  the  capability  necessary 
— to  receive  »  send  and  route  all  intra-system  messages 

— pertinent  to  TARGET-CONTROI _ 2-0*  In  addition  the 

--TRACK-MANAGER  is  responsible  for  the  maintenance 
— of  all  tables  uniaue  to  the  TARGET-C0NTR0L-2-0 
— activity. 
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procedure  TRACK-UPDATE-2-3-1  is 


—  Not  further  decomposed 

end  TRACK_UPDATE_2-3_1  I 

procedure  MANAGE-TABLES-2.3.2  is 

—  Not  further  decomposed 

end  MANAGE_TABI.ES_2.3_2  i 

procedure  DETERMINE_TRACK_STATUS_2_3_3  is 

—  Not  further  decomposewd 

end  DETERM I NE-TRACK_STATUS_2_3_3  i 

procedure  DATA-CONTROI _ 2_3_4  is 

—  Not  further  decoeposed 

end  DATA-CONTROI _ 2. 3-4  i 

procedure  0PERAT0R_SUITCH_ACTI0NS_2_3_5  is 

—  Not  further  decomposed 

end  OPERATOR-SU ITCH-ACT I 0NS_2_3_5  i 

end  TRACK-MANAGER-2-3  t 

package  bodw  C0UNTER-MEASURE-PR0CESSING-2-4  is 

COUNTER-MEASURE-PROCESSING. 2-4  Provides  all 
— activities  necessarw  to  provide  effective 
— identification  and  control  for  air  traffic 
— which  attempt  to  avoid  detection  throutfh  use 
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— of  Jamming  or  chaff  techniaues* 

procedure  JAM_STR0BE_PR0CESSING_2_4_1  is 

—  Not  further  decomposed 

end  JAM-STROBE -PROCESSING. 2-4_ 1  i 

procedure  CHAFF-PROCESSING-2-4-2  is 

—  Not  further  decomposed 

end  CHAFF-PROCESS I NG-2-4-2  I 

end  COUNTER-MEASURE-PROCESSING-2-4  i 

package  body  TARGET -ENG AGEMENT-2-5  is 

The  objective  of  TARGET _ENGAGEMENT_2_5  is  to 
— evaluate  the  threat  posed  to  defended  points  by 
— unknown  and  hostile  air  traffic*  After  calculation 
— of  the  threat  posed  by  each  track»  the  firr  unit(s) 
—best  Qualified  to  engage  that  particular  track  are 
— determined*  Upon  an  engagement  orderv 

— TARGET-ENGAGEMENT-2-5  is  responsible  foi  monitoring  all 
— engagements. 

procedure  EVALUATE-THREAT-2-5-1  is 

EVALUATE-THREAT-2-5-1  obtains  track  information 
— on  each  track  and  evaluates  the  threat  posed  by  that 
— track  to  each  defended  point.  The  threat  posed  by 
— each  track  once  for  each  scan* 

—  Not  further  decomposed 

end  EVALUATE_THREAT_2_5_1  i 

procedure  EVALUATE_WEAP0N_ASSIGNMENT_SC0RE_2_5_2  is 

EVALUATE-UEAP0N.ASSIGNMENT-SC0RE-2-5-2  computes 
— a  value  which  is  used  by  the  WEAP0N_ASSIGNMENT_2_5_3 
— activity  to  assign  a  target  to  the  appropriate  fire 
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— unit(s) 


—  Not  further  decomposed 

end  EVALUATE-WEAPON-ASSIGNMENT -SCORE-2-5-2  * 

procedure  WEAPON-ASSIGNMENT-2-5-3  is 

WEAPON-ASSIGNMENT -2-5-3  automatical ly  assigns  the 
— fire  unit(s)  best  Qualified  to  engage  hostile  air 
— tracks.  It  also  performs  bookeeping  operations  which  are 
— necessarw  to  maintain  stockpile  balancing  as  well  as 
— distinguish  between  weapons  tight  and  weapons  free. 

— In  the  weapons  tight  mode  assignment  of  unknown  tracks 
— made  be  accomplished  by  manual  operation  only. 

—  Not  fdurther  decomposed 

end  UEAPON-ASSIGNMENT-2-5-3  i 

procedure  M0NIT0R_ENGAGEMENT_2_5_4  is 

MONITOR-ENGAGEMENT-2-5-4  shll  provide  friendly 
— protection  by  monitoring  the  engagement  status  of 
— friendly  and  unknown  tracks.  In  addition*  it  shall 
— monitor  engaged  tracks  relative  to  safe  corridors. 

— Hold  fire  alerts  shall  be  issued  to 
— REMOTE_COMMUNICATION_3_0  if  engaged  targets  are 
— within  safe  corridors. 

—  Not  further  decomposed 

end  M0NIT0R_ENGAGEMENT-2_5-4  i 

end  TARGET-ENGAGEMENT-2-5  i 

end  T ARGET-CONTROI _ 2-0  * 


♦  T^PE  REMCOM.SDL 

package  REMOTE  COMMUNICATION  (3.0)  is 

—  The  objective  of  the  REMOTE  COMMUNICATION  SUBSYSTEM  (3.0) 

— is  to  enable  the  TSQ-73  to  co  tunicate  digitally  with 

— various  remote  sites  by  means  of  the  previously  defined 
— military  protocols?TADIL-B? ATDL-1 ?  and  MODIFIED  MBDL. 

—The  REMOTE  COMMMUNICATIONS  subsystem  shall  provide  fort 
-2  group  data  links  < ATDL-1 > 

-2  batallion  date  links  (ATDL-1) 

-1  tactical  operations  system  data  link  (ATDL-1) 

-1  air  traffic  management  system  data  link  (ATDL-1) 

-1  inter-service  communication  data  link  (ATDL-1) 

-A  fire  unit  data  links  (modified  MBDL) 

—  A  maximum  11  eleven  (11)  active  data  links  will  be  reauired  plus 
— on-line  redundant  data  transmission  links  for  each  active  link. 

— Thus*  a  total  of  22  active  links  plus  two  spare  links 

— will  be  reauired.  Each  link  will  be  capable  of  supporting 
— baud  rates  300?600?750? 1200*2400*4800  or  higher. 

Each  protocol  will  be  logically  and/or  physically 
— independent  from  the  operaton  of  a  different  protocol. 

— The  data  will  be  encrypted  at  the  point  of  transmission 
—and  decrypted  at  the  point  of  reception.  For  each  eight 
— bits  of  data  to  be  transmitted?  a  hamming  code  will  be 
—added  to  identify  multiple  bit  errors  and  correct  single- 
— bit  errors.  This  hamming  code  will  be  verified 
— or  reported  at  the  point  of  reception 

— where  the  hamming  code  will  be  removed  from  each  eight- 
— bit  seouence. 

Upon  initial  power-up?  all  data  link  paths  including 
— components  will  be  tested  and  exercised  with  a  basic  set 
— of  diagnostics.  Faulty  data  paths  will  be  identified  as  well 
— as  the  reason  for  their  fault.  These  faults  will  be 
— displayed  by  means  oft 
-system  console 
-status  display  panel 

-remote  communication  processor(s)  front  panel  indicator 
-error  lamps  on  the  malfunctioning  board  (processor? 
controller?  interf ace?modem?etc. )  which  may  be  cor¬ 
rected  by  removal  and  replacement  of  a  spare  board. 

Diagnostic  routines  will  be  executed  every  5  minutes  or 
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— upon  reauest  bv  the  system  operator  on  all  data  links  avail- 
--able  but  not  currently  utilized  for  transmission  or  reception* 

—  A  pool  of  available  data  links  will  be  utilized  bw  system 

—  initialization  and/or  sustain  operator  commands  to  determine 
— how  mans  and  what  protocol  twpe  will  be  used  with  which  data 
— links  and  at  which  particular  baud  rate*  Each  protocol 

— has  a  variety  of  safety  and  redundancy  features  built-in? 

— but  additional  system  retirements  to  terminate  or  auto- 
— aaticallw  activate  a  link  sre* 

—  -identification  of  a  data  link  fault 
-five  successive  checksum  errors 

On  a  power  fail  condition?  a  lamp  on  the  REMOTE  COM- 
— MUNICATION  processor(s)  front  panel  will  be  illuminated  and 
— the  power  fail  timer  started*  The  REMOTE  COMMMUNICATION 
— subsystem  will  retain  its  status  and  message  contents  for  a 
— minimum  of  24  hours* 

—  Upon  power  restoration?  an  automatic  restart  procedure  will 
— be  initiated  and  will  include* 

-notification  of  the  power  fail  condition  to  all  users- 
local  and  remote 

—  -resumption  of  communication  services 

—  -extinguishment  of  the  power  fail  lamp  on  the  front  panel 

—  A  number  of  operator  commands  will  be  available  to  generate 
— free-form  text  messages?  test  messages?  and  pre-defined 

— system  messages?  as  well  as  to  initiate  and  terminate  specific 
— links*  A  number  of  commands  will  be  available  to  provide 
— information  as  to  data  links?  message  buffers?  and  message 
— oueues  as  well  as  to  provide  a  single-ster  execution 
—capability  following  the  reception  or  transmission  of  a 
— message* 

—  Each  message  will  have  dual  link  transmission  and  recep- 
— tion  but  upon  reception  only  one  valid  message  copy  is 

—  reauired  for  intre-TSQ-73  retirements,  A  priority  message 
— structure  will  be  used  for  message  transmission*  A  message 
— broadcast  capability  to  all  links  with  a  single  message 
—will  be  provided. 

An  analysis  of  the  ouantity?size?  and  type  of  messages 
— flowing  in  and  out  of  the  system  is  not  available  since 
— detailed  analyses  of  other  major  packages  (COMMAND  AND 
—CONTROL? TARGET  CONTROL?  and  RADAR  COMMUNICATION  had 
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— not  boon  perforeed. 


package  COMMUNICATION  SUPERVISOR  (3.1)  is 

—The  objectives  of  the  COMMUNICATION  SUPERVISOR  are: 

—  1.  To  provide  a  controlling  interface  between  COMMAND 

AND  CONTROL*  TARGET  CONTROL* RADAR  COMMUNICATION*  and 
REMOTE  COMMUNICATON. 

— 2.  To  provide  for  the  aanageeent  of  the  REMOTE 

COMMUNICATION  package, 
procedure  CONSUME  INTERNAL  MESSAGE  (3.1.1): 
procedure  INITIALIZE  REMOTE  COMMUNICATION  (3.1.2): 
procedure  MANAGE  DATA  LINKS  (3.1.3): 
package  MANAGE  MESSAGES  (3.1.4): 

package  MANAGE  FAULT  DETECTION* CORRECTION  AND  REPORTING  (3.1.5): 
package  TERMINATE  REMOTE  COMMUNICATION  (3.1.6): 
procedure  PRODUCE  INTERNAL  MESSAGE  (3.1.7): 
end  COMMUNICATION  SUPERVISOR  (3.1): 


Package  bodv  COMMUNICATON  SUPERVISOR  (3.1)  is 
procedure  CONSUME  INTERNAL  MESSAGE  (3.1.1)  is 

Utilize  the  PUT  procedure  of  INTRASYSTEM  TRANSFER 
begin 
loop 

Validate  Message  origination 
if  COMMAND  AND  CONTROL  MESSAGE  or  COMMUNICATION  PROTOCOL 
MESSAGE  «  TRUE  then 

— Validate  Message  type  and  route  Message 
case  MESSAGE  TYPE  is 

— Message  type  'I'M  ALIVE*  handled  by  GET  procedure 
when  INITIALIZE  REMOTE  COMMUNICATION  => 

INITIALIZE  REMOTE  COMMUNICATION  (3.1.2): 
when  MANAGE  DATA  LINKS  =  > 

INITIATE  MANAGE  DATA  LINKS  (3.1.3): 
when  MANAGE  MESSAGES  => 

INITIATE  MANAGE  MESSAGES  (3.1.4): 
when  MANAGE  FAULT  DETECTION*  CORRECTION*  AND  REPORTING  *> 
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INITIATE  MANAGE  FAULT  DETECTION*  CORRECTION*  AND 
REPORTING  (3. 1*5)  I 

when  TERMINATE  REMOTE  COMMUNICATION  -> 

TERMINATE  REMOTE  COMMUNICATION  (3.1.6) ) 
when  OTHERS  «> 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  TYPE ) 

PRODUCE  INTERNAL  MESSAGE  (3.1.7)) 
end  case) 
else 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  ORIGINATOR) 

PRODUCE  INTERNAL  MESSAGE  (3.1.7)) 
end  if) 

DELAY  INTERNAL  TIMING  REQUIREMENT) 

The  internal  tieind  reauireeent  is  undetereined  at 
-this  tiee.  A  roudh  estiaate  places  this  value  in  the 
-50  esec  rnde.  The  final  value  will  be  detereined  at  the 
-tiee  of  swstea  integration  when  actual  aessade  flow  is 
-performed, 
end  loop) 

end  CONSUME  INTERNAL  MESSAGE  (3*1.1)) 


procedure  INITIALIZE  REMOTE  COMMUNICATION  (3.1*2)  is 
procedure  HOUSEKEEPING  (3. 1.2.1)  is 
bedin 

if  POWER  FAIL  FLAG  *  TRUE  then 
INITIATE  AUTOMATIC  RESTART) 

else 


CLEAR  MESSAGE  BUFFERS  (3. 1.2. 1.1)) 

CLEAR  MESSAGE  QUEUES  (3.1. 2. 1.2)) 

CLEAR  MESSAGE  COUNTERS  (3. 1.2. 1.3)) 

CLEAR  TRANSACTION  LOG  INDICATOR  (3. 1.2. 1.4)) 
CLEAR  POWER  FAIL  INDICATOR  (3. 1.2. 1.5)) 
end  if) 

end  HOUSEKEEPING  (3.1. 2.1>) 


Initialize  coeeunication  susbswstee  parameters 


Priaarw  and  redundant  line  addresses 

Association  of  routine  I.D.»  Data  link  addresses*  baud 


-rate*  protocol  assidnaents  and  transaction  lod  indicator. 
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procedure  INITIALIZE  COMM  SUBSYSTEM  PARAMETERS  <3. 1.2,2)  is 
bedin 

if  NON-DEFAULT  PARAMETERS  *  TRUE  then 


LOAD  NON-DEFAULT  PARAMETERS  (3. 1.2. 2.1)* 
else 

LOAD  DEFAULT  PARAMETERS  (3. 1.2. 2. 2)* 
end  if* 

-Initialize  coeeunication  tables  using  parameters 
procedure  INITIALIZE  COMM  TABLES  PARAMETERS 
(3. 1.2. 2. 3)  is 

INITIALIZE  DATA  LINK  TABLE  (3. 1 .2 .2 .3 . 1 ) * 
INITIALIZE  MESSAGE  TYPE  TABLE  (3. 1 .2. 2.3.2) * 

SET  TRANSACTION  LOG  FLAG  <3. 1.2. 2. 3.3)1 
end  INITIALIZE  COMM  TABLES  PARAMETERS  (3. 1.2.2. 3) * 
procedure  INITIATE  MANAGE  MESSAGES  (3. 1.2.3)* 
procedure  INITIATEMANAGE  DATA  LINKS  (3.1.2 .4)* 
end  INITIALIZE  COMM  SUBSYSTEM  PARAMETERS  (3. 1.2. 2) * 
end  INITIALIZE  REMOTE  COMMUNICATION  (3.1.2) * 


procedure  MANAGE  DATA  LINKS  (3.1.3)  is 

The  objective  of  the  MANAGE  DATA  LINKS  procedure  is  to 
-manage  the  data  link  table  and  the  initialization  and 
-termination  of  each  data  link, 
procedure  MANAGE  DATA  LINK  STATUS  TABLE  (3. 1.3.1)  is 
function  SEARCH  DATA  LINK  STATUS  TABLE  (3. 1.3. 1.1)) 
function  INSERT  ENTRY  DATA  LINK  STATUS  TABLE  (3.1. 3.1.2)* 
function  DELETE  ENTRY  DATA  LINK  STATUS  TABLE  (3. 1.3. 1.3)* 
procedure  INITIALIZE  LINK  (3. 1*3. 1.4)* 
procedure  TERMINATE  LINK  (3. 1.3. 1.5)* 
end  MANAGE  DATA  LINK  STATUS  TABLE  (3. 1.3.1)* 


procedure  MANAGE  PROTOCOLS  (3. 1.3. 2)  is 
begin 

case  PROTOCOL  is 
when  TADIL-B  *> 

INITIATE  TADIL-B  PROTOCOL  SUPERVISOR* 
when  ATDL-1  »> 
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INITIATE  ATDL-1  PROTOCOL  SUPERVISOR) 
when  MBDL  => 

INITIATE  HBDL  PROTOCOL  SUPERVISOR) 
when  others  => 

SET  ERROR  CODE  FOR  INVALID  PROTOCOL) 

PRODUCE  INTERNAL  MESSAGE  (3.1.7)? 
end  esse) 

end  MANAGE  PROTOCOLS  (3. 1.3.2)) 

procedure  MONITOR  PROTOCOLS  <3. 1,3. 2.1)  is 
bedin 

if  EOT  *  TRUE  then 
TERMINATE  DATA  LINK  <3,1.3. 2. 2>) 

REPORT  PROTOCOL  STATUS  (3.1.3.2.3)) 
end  if) 

end  MONITOR  PROTOCOLS  <3*1. 3. 2*1)) 
end  MANAGE  DATA  LINKS  <3.1.3) ) 


package  MANAGE  MESSAGES  <3.1.4)  is 
-  MANAGE  MESSAGES  has  been  decomposed  to  reveal 
-three  activities. 

procedure  MANAGE  OUTGOING  MESSAGES  <3* 1.4.1)) 
procedure  MANAGE  INCOMING  MESSAGES  <3, 1,4.2)) 
procedure  MANAGE  MESSAGE  BUFFERS  AND  QUEUES 
<3. 1.4. 3)) 

end  MANAGE  MESSAGES  <3.1.4)) 

package  bodw  MANAGE  MESSAGES  <3.1.4)  is 
procedure  MANAGE  OUTGOING  MESSAGES  <3. 1.4.1)  is 
procedure  DETERMINE  MSG  ACTION  <3. 1.4. 1.1)  is 
begin 

SELECT  HIGHEST  PRIORITY  MESSAGE  < return  MESSAGE) 
<3.1. 4. 1.1.1)) 

procedure  REPLICATE  MESSAGE  is 
begin 

if  MULTIPLE  MESSAGES  -  TRUE  then 
for  I  in  1.. NUMBER  OF  MAILBOXES  -  1  loop 
GET  MESSAGE  BUFFER < I ) ) 


COPY  MESSAGE  INTO  MAXLBOX( I >  r 
PRODUCE  INTERNAL  MESSAGE; 
end  loop; 
end  iff 

end  REPLICATE  MESSAGE; 
end  DETERMINE  MSG  ACTION  <3. 1*4.1. l>r 

procedure  POST  TRANSMISSION  ACTION  (3. 1.4. 1.2)  is 
bedin 

SELECT  HIGHEST  PRIORITY  MSG  (return  MSG) 

<3.1. 4.1.2. 1) ; 

POST  MESSAGE  STATUS; 

if  TRANSACTION  LOG  FLAG  and  ACK  REQUIRED  -  FALSE  then 
RELEASE  MESSAGE  BUFFER; 
end  if; 

if  TRANSACTION  LOG  FLAG  and  ACK  REQUIRED  -  TRUE  then 
REPLICATE  MESSAGE; 
end  if; 

PRODUCE  INTERNAL  MESSGE; 
end  POST  TRANSMISSION  ACTION  (3.1.4.1.2); 

procedure  PRE-TRANSMISSION  ACTION  is 
besin 

function  MESSAGE  TABLE  LOOKUP; 

Searches  aessade  tvpe  table  and  returns  eessade  type  and 

duplication  codes/i.d. 's. 

function  DATA  LINK  TABLE  LOOKUP; 

Searches  data  link  table  by  destination  i.d.  and  returns 
protocol  status?  data  link  availability?  and  protocol 
aailbox. 

MESSAGE  TYPE  -  MESSAGE  TABLE  LOOKUP; 
if  MESSAGE  TYPE  /-  OUTGOING  MESSAGE  TYPE  then 
SET  ERROR  CODE  FOR  INVALID  OUTGOING  MESSAGE; 

PRODUCE  INTERNAL  MESSAGE; 
end  if; 

LINK  -  DATA  LINK  TABLE  LOOKUP; 
if  PROTOCOL  STATUS  -  INACTIVE  then 
SET  ERROR  CODE  FOR  INACTIVE  PROTOCOL; 

PRODUCE  INTERNAL  MESSAGE; 


if  DATALINK  AVAILABILITY  =  FALSE  then 
SET  ERROR  CODE  FOR  INACTIVE  DATA  LINK? 
PRODUCE  INTERNAL  MESSAGE? 
end  if? 

REPLICATE  MESSAGE? 

PRODUCE  INTERNAL  MESSAGE? 
end  PRE  TRANSMISSION  ACTION? 


loop 

if  MESSAGE  QUEUE  COUNT  >  0  THEN 
SELECT  HIGHEST  PRIORITY  MESSAGE? 
if  POST  TRANSMISSION  FLAG  -  TRUE  THEN 
POST  TRANSMISSION  ACTION 
else 

PRE  TRANSMISSION  ACTION? 
end  if? 
end  if? 

DELAY  INTERNAL  TIMING  REQUIREMENT? 
end  loop? 

end  DETERMINE  MSG  ACTION  <3.1. 4*1. 1>? 
end  MANAGE  OUTGOING  MESSAGES  <3.1. 4.1)? 

Procedure  MANAGE  INCOMING  MESSAGE  <3. 1.4.2)? 
— Not  decomposed  for  validation  effort 


procedure  MANAGE  MESSAGE  BUFFERS  AND  QUEUES  <3. 1.4.3)? 
— Not  decomposed  for  validation  effort 


end  MANAGE  MESSAGES  <3.1.4)? 


package  MANAGE  FAULT  DETECTION* CORRECTION  AND  REPORTING 
<3. 1 *5)  is 

procedure  IDENTIFY  FAULTS  <3.1. 5.1)? 
procedure  UPDATE  ERROR  COUNTERS  <3. 1.5. 2)? 
procedure  ATTEMPT  CORRECTIVE  ACTION  <3. 1.5. 3)? 
procedure  REPORT  FAULTS  <3. 1.5.4)? 
end  MANAGE  FAULT  DETECT I ON* CORRECT I ON  AND  REPORTING  <3.1.5)? 


package  body  MANAGE  FAULT  DETECT I ON » CORRECT I ON  AND  REPORTING 
(3*1*5)  is 

procedure  IDENTIFY  FAULTS  <3* 1.5.1)  is 
procedure  IDENTIFY  HARDWARE  FAULTS  <3.1. 5.1.1)) 
procedure  IDENTIFY  SOFTWARE  FAULTS  <3. 1.5. 1.2)1 
end  IDENTIFY  FAULTS  (3.1.5.1)) 

end  MANAGE  FAULT  DETECTION .CORRECTION  AND  REPORTING  (3.1.5)J 


package  TERMINATE  REMOTE  COMMUNICATON  (3.1.6)  is 
procedure  BUILD  TERMINATION  MESSAGE  (3. 1.6.1)) 
procedure  START  TERMINATE  DATA  LINK  <3. 1.6. 2)) 
procedure  UPDATE  DATA  LINK  STATUS  TABLE  (3. 1.6. 3)) 
procedure  STOP  DATA  LINK  MANAGER  (3. 1.6.4)) 
procedure  STOP  MESSAGE  MANAGER  (3. 1.6. 5)) 
procedure  UPDATE  TRANSACTION  LOG  (3. 1.6.6)) 
end  TERMINATE  REMOTE  COMMUNICAION  (3.1.6)) 


procedure  PRODUCE  INTERNAL  MESSAGE  (3.1.7)  is 
begin 

if  INTERNAL  MESSAGE  QUEUE  NOT  EMPTY  then 
GET  MESSAGE  FROM  QUEUE  (3. 1.7.1)) 
case  INTENRAL  ROUTING  ID  is 
when  COMMAND  AND  CONTROL  or  TARGET  CONTROL  or 
RADAR  COMMUNICATION  »> 

PUT  MESSAGE  TO  COMMAND  AND  CONTROL) 
when  COMMUNICATION  PROTOCOL  => 

PUT  MESSAGE  TO  COMMUNICATION  PROTOCOL  <3. 1.7.2)) 

when  others  *> 

SET  ERROR  CODE  FOR  INVALID  INTERNAL  ROUTING  I.D.) 
PUT  ERROR  CODE  TO  COMMAND  AND  CONTROL) 

end  case) 

end  if) 


end  PRODUCE  INTERNAL  MESSAGE  (3.1.7)) 


end  COMMUNICATION  SUPERVISOR  (3.1.) 5 


package  INTRASYSTEM  TRANSFER  (3.2)  is 

—  The  objective  of  the  intrasvstea  transfer  subentity  is  to 
— provide  facilities  which  allow  aessage  flow  between  the 
—REMOTE  COMMUNICATOR  and  COMMAND  AND  CONTROL  (RADAR  COM- 

— MUNI CATION  and  TARGET  CONTROL)  as  well  as  support  aessage 
—flow  within  the  REMOTE  COMMUNICATION?  i.e.r  between 
—the  REMOTE  COMMUNICATOR  supervisor  and  the  coaaunicaton 
— protocols.  To  insure  aessade  flow  integrity ? intra-system 
— transfers  will  eaploy  aailbox  concepts  with  seaaphore 
— counters  and  aessade  tiae  staaps  to  identify  potential 
— bottlenecks  and  provide  periodic  status  reports  as  needed. 

—  The  INTRASYSTEM  TRANSFER  package  is  initiated  and 
— terainated  by  COMMAND  AND  CONTROL. 

—  The  INTRASYSTEM  TRANSFER  package  is  intended  to  operate 
— concurrently  with  various  other  operations  and  is  itself 

— coaprised  of  a  MESSAGE  POSTING  TIMER  procedure  and  two  other 
— procedures ?  GET  INTRASYSTEM  TRANSFER  and  PUT  INTRASYSTEM 
—TRANSFER. 

The  following  descriptions  assuae  that  the  COMMAND 
— AND  CONTROL  package  has  generic  aailbox  features  which 
— utilize  the  seaaphore  concept.  The  initialization 
—function  of  COMMAND  AND  CONTROL  will  initialize  the 
— proper  nuaber  and  type  of  aailboxes  necessary  to 
— iarleaent  this  activity. 

Mailboxes  are  rroducer-consuaer  points?  the  nuaber 
— of  which  is  deterained  at  initialization  tiae  bw  the 
—nuaber  of  protocols?  the  coaaunication  supervisor? 

—and  the  COMMAND  AND  CONTROL  package, 
procedure  GET  INTRASYSTEM  TRANSFER  (3.2.1  )$ 
procedure  PUT  INTRASYSTEM  TRANSFER  (3.2.2)$ 
procedure  MESSAGE  POSTING  TIMER  (3.2.3)$ 
end  INTRASYSTEM  TRANSFERS  (3.2) $ 


package  body  INTRASYSTEM  TRANSFER  (3.2)  is 
procedure  GET  INTRASYSTEM  TRANSFER  (3.2*1)  is 
—  The  get  and  put  features  of  the  INTRASYSTEM  TRANSFER 
— package  may  be  implemented  in  two  ways.  The  first  method 
— is  to  have  each  mailbox  employ  its  own  get  and  put 
— procedures.  The  second  method  is  separate  procedures 
— for  get  and  put  with  multiple  mailboxes  -  a  logical 
— multiplexer, 
begin 

for  I  in  I ..NUMBER  OF  MAILBOXES  loop 
TIMEOUT  FLAG ( I )  -  FALSE ) 
end  loop) 
loop 

for  I  in  I.. NUMBER  OF  MAILBOXES  loop 
if  GET  MESSAGE  BUFFER  *  EMPTY  then 
if  TIMEOUT  FLAG(I)  =  TRUE  then 
ISSUE  PRODUCER  ERROR » 

TIMEOUT  FLAG ( I )  *  FALSE) 
else 

TIMEOUT  FLAG ( I )  *  TRUE) 
end  if) 
else 

TIMEOUT  FLAG ( I )  *  FALSE) 

GET  MESSAGE  FROM  BUFFER < I )  ) 

UPDATE  TIME  STAMP  QUEUE(I)) 

— Determine  message  type 

if  MESSAGE  -  ■I'M  ALIVE1  then 
DISCARD  MESSAGE) 
else 

MESSAGE  AVAILABLE  FOR  PROCESSING) 
end  if) 
end  if) 

DELAY  INTERNAL  TIMING  REQUIREMENT) 
end  loop) 

end  GET  INTRASYSTEM  TRANSFER  (3.2.1)) 


procedure  PUT  INTRASYSTEM  TRANSFER  (3.2.2)  is 
-  The  get  and  put  features  of  the  INTRASYSTEM  TRANSFER 
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— procedure  maw  be  implemented  in  two  wavs.  The  first  method  is 
— to  have  each  mailbox  employ  its  own  met  and  put  procedures* 

— The  second  method  is  separate  procedure  for  set  and  put  with 
— multiple  mailboxes  -  a  logical  multiplexer, 
procedure  TEST  BUFFER  (DESTINATION)  is 
bedin 

if  DESTINATION  BUFFER  «* NOT  EMPTY  then 
if  DESTINATION  TIMEOUT  FLAG  =  TRUE  then 
ISSUE  CONSUMER  ERROR) 

DESTINATION  TIMEOUT  FLAG  *  FALSE) 
else 

DESTINATION  TIMEOUT  FLAG  =  TRUE) 
end  if) 
else 

PUT  MESSAGE  IN  DESTINATION  MAILBOX) 

DESTINATION  TIMEOUT  FLAG  =  FALSE) 
end  if) 

end  TEST  BUFFER) 
begin 
loop 

ACCEPT  MESSAGE  (MESSAGE)) 

DETERMINE  DESTINATION)  —FROM  MESSAGE  CONTENT 
case  DESTINATION  is 

when  COMMAND  AND  CONTROL  or  TARGET  CONTROL  or 
RADAR  COMMUNICATION  => 

TEST  BUFFER  (COMMAND  AND  CONTROL)) 
when  COMMUNICATION  SUPERVISOR  => 

TEST  BUFFER  (COMMUNICATION  SUPERVISOR)) 
when  TADIL-B  PROTOCOLS 
TEST  BUFFER  (TADIL-B  PROTOCOL)) 
when  ATDL-1  PROTOCOL  => 

TEST  BUFFER  (ATDL-1  PROTOCOL)) 
when  MBDL  PROTOCOL  -> 

TEST  BUFFER  (MBDL  PROTOCOL)) 
end  case) 

DELAY  INTERNAL  TIMING  REQUIREMENT) 
end  loop 


end  PUT  INTRASYSTEM  TRANSFER  (3.2.2)) 


procedure  MESSAGE  POSTING  TIMER  <3.2.3)  is 
procedure  CONSUMER  TIMER  <3. 2. 3. 1)5 
begin 
loop 

for  I  in  I.. NUMBER  OF  MAILBOXES  loop 
if  GET  MESSAGE  BUFFER < I )  =  NOT  EMPTY  then 
if  CURRENT  TIME  -  TIME  STAMP(I)  > 

INTERNAL  TIMING  REQUIREMENT  then 
ISSUE  TIMEOUT  ERROR ( I ) > 
end  if; 

if  SEMAPHORE  COUNTER(I)  >  MAX  MESSAGES  OR  SEC  then 
ISSUE  SEMAPHORE  ERROR<I>$ 
end  if» 
end  iff 
end  loop; 

DELAY  INTERNAL  TIMING  REQUIREMENT ; 
end  loop; 

end  CONSUMER  TIMER  <3. 2. 3.1)? 


procedure  PRODUCER  TIMER  <3. 2. 3. 2)  is 
begin 
loop 

for  I  in  I.. NUMBER  OF  MAILBOXES  loop 
if  PUT  MESSAGE  BUFFER(I)  =  EMPTY  then 
if  CURRENT  TIME  -  TIME  STAMP  > 

INTERNAL  TIME  REQUIREMENT  then 
BUILD  *  I '  M  ALIVE*  MESSAGE  f 
PUT  *  I '  M  ALIVE*  MESSAGE  IN  MAILBOX(I); 
end  iff 
elseif 

SEMAPHORE  COUNTERU)  >  MAX  MESSAGES  OR  SEC  then 
ISSUE  SEMAPHORE  ERROR; 
end  if! 
end  loop; 

DELAY  INTERNAL  TIMING  REQUIREMENT; 
end  loop; 

end  PRODUCER  TIMER  (3. 2. 3. 2); 

Additional  details  (Queue  nanageeentf  buffer  nanasement f  inter- 
ernal  routing  tablef  etc.)  are  not  included  due  to  project 
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— schedule  restrictions* 
end  MESSAGE  POSTING  TIMER  (3.2*3)$ 
end  INTRASYSTEM  TRANSFERS  (3.2)$ 


package  COMMUNICATION  PROTOCOL  (3.3)  is 

The  objective  of  the  COMMUNICATION  PROTOCOL  package  is  to 
— handle  the  physical  level  of  the  transmission  and  reception 
— of  digital  messages  according  to  the  predefined  military 
— protocols  TADIL-Bf ATDL-1 »  and  modified  MBDL. 

—  The  COMMUNICAION  PROTOCOL  package  is  initiated  end 
—terminated  by  COMMUNICATION  SUPERVISOR  (3.1). 

procedure  TADIL-B  SUPERVISOR  (3.3.1)$ 

—NOT  INVESTIGATED 
procedure  ATDL-1  SUPERVISOR  (3.3.2)$ 

—NOT  INVESTIGATED 

procedure  MBDL  PROTOCOL  SUPERVISOR  (3.3.3)$ 

MBDL  PROTOCOL  SUPERVISOR  is  a  bisynchronous  protocol 
— utilizing  full  duplex  data  lines  with  point-to-point 
— transmission* 

procedure  COMSUME  COMMUNICATION  SUPERVISOR  MESSAGE  (3. 3. 3.1)$ 

procedure  INITIALIZE  DATA  LINE  (3. 3. 3,2)$ 

procedure  TRANSMIT  MESSAGE  (3. 3. 3.3)$ 

procedure  RECEIVE  MESSAGE  (3. 3. 3,4)$ 

package  PROTOCOL  UTILITIES  (3.3. 3.5)$ 

procedure  TERMINATE  DATA  LINK  (3. 3. 3.6)$ 

procedure  PRODUCE  COMMUNICATION  SUPERVISOR  MESSAGE  (3. 3. 3.7)$ 
end  MBDL  PROTOCOL  SUPERVISOR  (3.3.3)$ 
end  COMMUNICATON  PROTOCOL  (3.3)$ 


package  body  COMMUNICATON  PROTOCOL  (3.3)  is 
procedure  MBDL  PROTOCOL  SUPERVISOR  (3.3.3)  is 

procedure  CONSUME  COMMUNICATION  SUPERVISOR  MESSAGE  (3.3.3. 1) 
is 

begin 

loop 
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Utilize  the  GET  Procedure  of  INTRASYSTEM  TRANSFER 
validate  aessade  originator 


if  COMM  SUPERVISOR  MESSAGE  *  TRUE  then 
validate  aessade  type  and  routes  aessade 

case  MESSAGE  TYPE  is— aessade  type  *  I ' M  ALIVE1  handled  by 
GET  procedure 

when  INITIALIZE  MESSAGE  TYPE  =>  QUEUE  TO 
INITIALIZE  DATA  LINK  <3.3.3*2>; 
when  TRANSMIT  MESSAGE  *>  QUEUE  TO  TRANSMIT 
MESSAGE  <3*3. 3.3)1 

when  UTILITY  MESSAGE  TYPE  =>  QUEUE  TO 
PROTOCOL  UTILITIES  (3. 3. 3.5)5 
when  TERMINATE  MESSAGE  TYPE  =>  QUEUE  TO 
TERMINATE  DATA  LINK  <3.3.3.6>; 
when  others  => 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  TYPE? 

QUEUE  TO  PRODUCE  COMM  SUPERVISOR  MSG  (3. 3. 3. 7); 
end  case* 
else 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  ORIGINATOR; 

QUEUE  TO  PRODUCE  COMM  SUPERVISOR  MSG  <3.3.3.7>; 
end  if» 

DELAY  INTERNAL  TIMING  REQUIREMENT; 
end  loop; 

end  CONSUME  COMMUNICATION  SUPERVISOR  MESSGE  (3.3.3.1); 


procedure  INITIALIZE  DATA  LINK  <3.3.3.2>  is 
procedure  CONNECT  DATA  LINK  <3. 3, 3. 2*1)  is 
bedin 

START  DATA  LINK  SELF  TEST  ( 3 . 3 . 3 . 2 . 1 . 1 ) ; 

START  INITIALIZE  LINE  <3. 3. 3. 2. 1 .2) ; 

START  LINE  SUPERVISOR  (3 . 3 . 3 . 2 . 1 .3 )  ; 

START  DATA  LINK  LOOPBACK  TEST  <3*3. 3.2 . 1 . 4 > ; 
end  CONNECT  DATA  LINK  <3. 3. 3. 2.1); 

procedure  START  PROTOCOL  FOR  DATA  LINK  <3. 3. 3. 2,2 >; 
procedure  TRANSMIT  INITIALIZATION  MESSAGE  <3. 3.3. 2.3); 
procedure  VALIDATE  DATA  LINK  PATH  <3. 3. 3. 2. 4) ; 
procedure  QUEUE  DATA  LINK  AND  PROT  STAT  TO  PROD  COMM  SUPER  MSG 
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(3. 3*3*2. 5) t 


•nd  INITIALIZE  DATA  LINK  (3. 3. 3. 2)} 


procedure  TRANSMIT  MESSAGE  (3*3. 3. 3)  is 

procedure  ENCODE  MESSAGE  TO  PROTOCOL  (3. 3. 3*3*1)  is 
begin 
loop 

procedure  SELECT  MESSAGE  FOR  ENCODING  <3. 3*3. 3 . 1 . 1 )  is 
begin 

if  MESSAGE  QUEUE  COUNT  >  ENCODED  MESSAGE  QUEUE  COUNT 
then 

SELECT  HIGHEST  PRIORITY  MESSGE  ( 3 * 3 *3 * 3 . 1  * 2 ) $ 

ENCODE  MESSAGE  HEADER  (3.3. 3. 3. 1.3)} 

ENCODE  MESSAGE  TEXT  (3 . 3 .3 . 3 . 1  * 4 > I 
if  TEXT  FORM  =  PREDEFINED  FORM  then 
ENCODE  PREDEFINED  TEXT » 
else 

ENCODE  FREE  FORM  TEXT  $ 
end  if} 

ENCODE  MESSAGE  TRAILER  <3. 3. 3. 3. 1 .5) } 

— Checksum  calculations  if  not  calculated  in  transei t/receive 
— character* 

ASSEMBLE  MESSAGE  FRAME  (3. 3. 3*3. 1.6)} 

UPDATE  MESSAGE  TRANS  AVAIL  (3*3*3. 3 . 1 .7) } 

UPDATE  ENCODED  MESSAGE  QUEUE  COUNT  (3.3. 3. 3. 1.8)1 
end  iff 

DELAY  INTERNAL  TIMING  REQUIREMENT  ) 
end  SELECT  MESSAGE  FOR  ENCODING  (3. 3.3. 3. 1.1)1 
end  loop! 

end  ENCODE  MESSAGE  TO  PROTOCOL  (3. 3. 3. 3.1)} 

procedure  SEND  MESSAGE  (3. 3. 3. 3. 2)) 
begin 

procedure  SELECT  MESSAGE  FOR  TRANSMISSION  (3. 3 . 3 . 3 . 2. 1 )  is 
begin 
loop 

if  ENCODED  MESSAGE  QUEUE  >  0  then 
SELECT  HIGHEST  PRIORITY  MESSAGE  (3. 3. 3. 3. 2. 1 . 1 ) } 
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— Select  highest  priority  aessade  is  the  seme  ss  3»3*3»3»1*1> 

— but  is  repeated  here  because  this  procedure  aay  be  executing 
— on  a  different  processor* 

DATA  LINK  TABLE  LOOKUP  (3*3*3* 3* 2*1*2)) 

— Searches  the  data  link  table  by  destination  i.d.  and  returns 
--physical  line  numbers  for  both  priaary  and  redundant  lines* 
if  PRIMARY  LINE  NUMBER  and  REDUNDANT  LINE  NUMBER 
NOT  VALID  then 

SET  ERROR  CODE  < INVALID  OR  INACTIVE)  FOR  BOTH  LINES) 
QUEUE  TO  PRODUCE  COMM  SUPERVISOR  MSG  <3. 3*3*7)) 
else  if 

PRIMARY  LINE  NUMBER  and  REDUNDANT  LINE  NUMBER  VALID 
then 

INSERT  PRIMARY  LINE  NUMBER  INTO  MESSAGE) 

INSERT  REDUNDANT  LINE  INTO  MESSAGE) 

QUEUE  MSG  TO  POST  MSG  TO  LINE  ( 3 . 3 * 3 * 3 . 2 . 1 . 3 ) ) 
else  if 

PRIMARY  LINE  VALID  then 
INSERT  PRIMARY  LINE  NUMBER  INTO  MESSAGE) 

SET  ERROR  CODE  (INVALID  OR  INACTIVE)  FOR  PRIMARY 
LINE) 

QUEUE  MSG  TO  POST  MSG  TO  LINE  (3*3. 3. 3. 2* 1 *3) ) 

•  else 

INSERT  REDUNDANT  LINE  NUMBER  INTO  MESSAGE) 

SET  ERROR  CODE  (INVALID  OR  INACTIVE)  FOR  PRIMARY  LINE) 
QUEUE  MSG  TO  POST  MSG  TO  LINE  ( 3 .3 . 3. 3 . 2 . 1 . 3) ) 
end  if) 
end  if) 

DELAY  INTERNAL  TIMING  REQUIREMENT) 
end  loop) 

procedure  POST  MESSAGE  TO  LINE  (3. 3. 3*3. 2* 1 .3)  is 
bedin 

if  INITIALIZATION  MESSAGE  then 
POST  MESSAGE  TO  LINE(I)) 

Where  I  is  the  physical  line  number 

POSTING  MESSAGE  TIMER  (3 . 3. 3 * 3 .2 . 1 .3.3 ) ) 
end  if) 

procedure  POST  MESSAGE  TO  PRIMARY  LINE  ( 3 . 3 . 3*3 .2. 1 . 3. 1 )  is 
bedin 
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loop 

if  PRIMARY  LINE(I)  AVAILABLE  and  ENCODED  MESSAGE ( I > 
AVAILABLE  then 
POST  MESSAGE  TO  LINE(I>) 

•  Iso 

DELAY  UPON  PRIMARY  LINE(I)  AVAILABILITY) 

ENCODED  MESSAGE < I )  AVAILABILITY) 

•nd  if) 

•nd  loop) 

•nd  POST  MESSAGE  TO  PRIMARY  LINE  < 3 .3 .3.3.2 . 1 .3. 1 > ) 

procedure  POST  MESSAGE  TO  REDUNDANT  LINE  <3. 3. 3. 3. 2. 1 .3.2) ) 
begin 
loop 

IF  REDUNDANT  LINE(I)  AVAILABLE  end  ENCODED  MESSAGE ( I ) 
AVAILABLE  then 
POST  MESSAGE  TO  LINE<I>) 
else 

DELAY  UPON  REDUNDANT  LINE(I)  AVAILABILITY  or 
ENCODED  MESSAGE ( I )  AVAILABILITY) 
end  if) 
end  loop) 

end  POST  MESSAGE  TO  REDUNDANT  LINE  <3. 3. 3. 3. 2. 1.3. 2)) 

procedure  POSTING  MESSAGE  TIMER  (3. 3*3. 3. 2 . 1 .3.3 ) ) 

The  objective  of  the  POSTING  MESSAGE  TIMER  is  to  issue 
(set  error  code  and  oueue  to  comb  supervisor  task)  a  posting 
tiae-out  error.  This  is  when  a  Message  cannot  be  posted  to 
a  specific  active  line  within  a  specific  tiae  interval  which 
is  in  relation  <<*>)  to  the  interval  tiaing  reauireaent.  This 
is  not  investigated  further. 

end  SELECT  MESSAGE  FOR  TRANSMISSION  <3. 3.3. 3. 2. 1 > ) 


procedure  LINE  PROTOCOL  MANAGER  (3. 3. 3. 3. 2. 2)  is 
procedure  PROTOCOL  REQUIREMENTS  <3 .3.3.3 .2 .2 . 1 )  is 
begin 

Procedure  DISASSEMBLE  MESSAGE  FRAME  <3. 3. 3. 3. 2. 2. 1 . 1 ) ) 


D-63 


procedure  SUPERVISOR  LINE  <3*3*3. 3. 2. 2. 1 .2) » 
procedure  LINE  I/O  DRIVER  <3. 3. 3*3. 2. 2*1 .3)  is 
INITIALIZE  LINE  <3.3 . 3. 3.2 . 2. 1 .3. 1 ) t 
procedure  TRANSMIT  CHARACTER  <3*3. 3*3. 2*2. 1.3. 2)  is 
bedin 

CHECKSUM  CALCULATION  <3. 3. 3. 3. 2. 2* 1 .3.2. 1 ) * 

ENCRYPT  CHARACTER  <3. 3. 3. 3.2. 2. 1 .3.2.2) ♦ 

CALC  CHAR  HAM  CODE  <3. 3. 3. 3. 2. 2.1 .3.2. A) t 
CHARACTER  TIME  OUT  <3. 3. 3. 3. 2. 2. 1 .3.2.4) » 
end  TRANSMIT  CHARACTER  <3. 3.3. 3. 2. 2. 1 .3.2) * 
procedure  RECEIVE  CHARACTER  <3 . 3 .3. 3. 2. 2 . 1 .3.3)  is 
bedin 

VERIFY  CHAR  HAMM  CODE  <3.3 .3 .3.2 .2 . 1 ,3.3. 1 ) * 

DECRYPT  CHARACTER  < 3 . 3 . 3 . 3 . 2 . 2 . 1 .3 .3 . 2 > ) 

CHECKSUM  CALCULATION  < 3 . 3. 3 . 3. 2 .2. 1 . 3.3.3) i 
CHARACTER  TIME  OUT  <3. 3. 3. 3. 2. 2.1 .3.3.4) t 
end  RECEIVE  CHARACTER  < 3. 3. 3.3. 2. 2. 1 .3.3) f 
TERMINATE  LINE  <3. 3. 3. 3.2. 2. 1 .3.4) t 
REAL  LINE  STATUS  <3. 3. 3. 3. 2. 2. 1 .3.5) I 
LOOP  BACK  TEST  <3. 3. 3.3. 2. 2.1 .3.6) t 
SELF  TEST  <3 . 3 .3.3 .2 . 2 . 1 . 3 .7 > * 

AUTOMATIC  DIAL  <3. 3, 3. 3. 2. 2. 1 ,3.8) ) 

AUTOMATIC  ANSWER  <3. 3.3.3. 2. 2.1 .3.9) I 
EXCEPTION  HANDLER  <3.3.3.3.2.2.1.3.10)) 
end  LINE  I/O  DIRVER  <3. 3. 3. 3. 2. 2.1. 3) ) 
procedure  MONITOR  DISPLAY  MODE  <3. 3. 3. 3.2 .2. 1 .4) ) 

Use  to  displeu  cherecter  transmission  to  e  terminal 
bedin 

TERMINAL  COMMANDS  < 3,3 .3 , 3 . 2. 2. 1 . 4 . 1 ) t 
TERMINAL  I/O  DRIVER  <3. 3 .3.3 , 2 . 2 . 1 . 4 .2) ) 
end  MONITOR  DISPLAY  MODE  <3. 3. 3. 3. 2. 2.1 .4) ) 

REPORT  MESSAGE  TRANSMISSION  STATUS  <3. 3. 3. 3. 2.2. 1 .5) I 
end  PROTOCOL  REQUIREMENTS  <3. 3. 3. 3, 2. 2.1>) 
end  LINE  PROTOCOL  MANAGER  <3. 3.3. 3. 2. 2) f 
end  SEND  MESSAGE  <3. 3. 3. 3. 2)) 


procedure  RECEIVE  MESSAGE  <3. 3. 3. 4)  is 
not  decomposed  for  validation  effort 
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end  RECEIVE  MESSAGE  (3. 3.3.4)  I 


packs**  PROTOCOL  UTILITIES  (3.3.3.S)  is 
—  The  objective  is  to  provide  utilities  (displawrlist»*odifw) 
— capabilities  into  the  coaaunication  protocol.  These  utilities 
— will  not  be  decomposed  further  but  are  listed  for  completeness 
packs**  BUFFER  UTILITIES  (3.3.3. 5.1>) 
packs**  DATA  LINK  TABLE  UTILITIES  (3. 3. 3. 5. 2)1 
packs**  MAILBOX  UTILTIES  (3. 3. 3. 5. 3) I 
SEMAPHORE  UTILITES  <3. 3. 3. 5. 4)) 

TASK  PROCEDURE  UTILITIES  <3. 3. 3. 5. 5)) 
end  PROTOCOL  UTILITIES  (3. 3.3. 5)) 


procedure  TERMINATE  DATA  LINK  (3.3. 3. 6)  is 
— Not  decomposed  for  validation  effort 

procedure  TRANSMIT  TERMINATION  MESSAGE  <3. 3. 3.6.1)) 
procedure  HALT  PROTOCOL  FOR  DATA  LINK  (3. 3. 3. 6. 2)) 
procedure  DISCONNECT  DATA  LINK  <3. 3. 3. 6. 3>) 

procedure  QUEUE  DATA  LINK  AND  PROT  STAT  TO  PRODUCE  COMM  SUPER 
MSG  (3*3. 3. 3*6. 4)) 
end  TERMINATE  DATA  LINK  (3. 3.3. 6) ) 


procedure  PRODUCE  COMM  SUPERVISOR  MESSAGE  (3.3.3.7H 
be*in 
loop 

DEQUEUES  MESSAGE  FROM  COMM  SUPERVISOR  QUEUES  (3. 3*3. 7.1)) 
PUT  MESSAGE  (3. 3*3. 7. 2)1 
—Utilizes  the  put  task  of  INTRASYSTEM  TRANSFER 
end  loop) 

DELAY  INTERNAL  TIMING  REQUIREMENT) 
end  PRODUCE  COMM  SUPERVISOR  MESSAGE  (3. 3.3.7)) 
end  MBDL  PROTOCOL  SUPERVISOR  (3.3.3)) 
end  COMMUNICATION  PROTOCOL  (3.3)) 
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'  • 

♦  TVfc:  RADAR. SDL 

MCkM«  RADAR  COMMUNICATION  (4.0)  is 

RADAR  COMMUNICATION  will  execute  concurrently  with 
--REMOTE  COMMUNICATIONS  >  COMMAND  t  CONTROL  and  TARGET 
—CONTROL  packages. 

The  objective  of  the  radar  coeeunicetion  subsystem  is  to 
— enable  the  T8Q.73  to  communicate  digitally  (analog 
— conversion  will  be  performed  bw  the  radar  sites) 

— with  various  local  and  reeote  sites  bw  Means 
— of  the  rreviouslv  defined  ailitarw  radar  interface 
— ( ATDL-1 ) . 

The  radar  coeeunication  subswstee  shall  provide 
— ATDL-1  data  links  to  four  (4)  radar  sites. 

A  aaxieua  of  four  (4)  active  full  duplex  data  links  will  be 
— reouired  plus  on-line  redundant  data  transmission  links 
— for  each  active  link.  Thus,  a  total  of  eight  (8)  active  links 
— plus  a  minimum  of  two  spare  links  will  be  reauired.  Each 
— link  will  be  capable  of  supporting  baud  rates  of  300.  600. 
—750.  1200.  1500.  2400*  4800.  9600  or  higher. 

The  data  will  be  encrvpted  at  the  point  of  transmission 
— and  decrvpted  at  the  point  of  reception.  For  each  eight 
— bits  of  data  to  be  transmitted,  a  hamming  code  will  be 
— added  to  identify  multiple-bit  errors  and  correct  single- 
— bit  errors.  This  hamming  code  will  be  verified  or  reported 
— at  the  point  of  reception  and  the  hamming  code  will  be 
— removed  from  each  eight  bit  seouence. 

Upon  initial  power-up.  all  data  link  paths  including 
— components  will  be  tested  and  exercised  with  a  basic  set 
— of  diagnostics.  Faulty  data  paths  will  be  identified  as 
—well  as  the  reason  for  their  fault.  These  faults  will  be 
— displayed  bw  means  ofi 
-system  console 
-status  display  panel 

-radar  communications  processor(s)  front  panel  indicator 
-error  lames  on  the  malfunctioning  board  (processor, 
controller,  interface,  modem,  etc.)  which  maw  be 
corrected  bw  removal  and  replacement  of  a  spare  board. 
Diagnostic  routines  will  be  executed  every  five  minutes 
—or  upon  reouest  bw  the  system  operator  on  all  data  links 
— available  but  not  currently  utilized  for  transmission  or 
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— reception . 

—  A  pool  of  available  data  links  will  ba  utilized  by 

— systea  initialization  paraaeters  and/or  systea  operator 
-- coaaands  to  deteraine  how  aanw  will  be  used  with  which 
— data  links  and  at  which  particular  baud  rate*  Radar 
— interface  protocols  have  a  variety  of  safety  and 
— redundancy  features  built-in*  but  additional  system 
— reouireaents  to  terainate  or  autoaatically  activate  a 
— data  link  are* 

-identification  of  a  data  link  fault* 

-five  successive  checksua  errors* 

Upon  a  power  fail  condition*  a  laap/indicator  on  the 
—radar  coaaunications  processor(s)  front  panel  and  the 
— status  display  panel  will  be  illuainated  and  the  power 
— fail  tiaer  initialized  and  started*  The  radar  coaaunication 
— subsystem  will  retain  its  status  and  aessade  contents  for 
— a  ainiaua  of  24  hours* 

Upon  power  restoration*  an  autoaatic  restart  pro- 
— cedure  will  be  initiated  which  will  include! 

-Power-fail  duration  of  less  than  one  second 
o  Notification  of  the  power  fail  condition  and 

—  duration  to  the  svstea  console  device* 
o  Resumption  of  coaaunication  services* 

o  Extinguish  the  power  fail  laap/indicator  on 
the  processor  front  panel  and  the  status 
display  panel. 

--  -Power-fail  duration  of  dreater  than  one  second 

and  less  than  the  radar  scan  tiae  of  360  dedrees 
(3*  6  or  10  seconds)* 

o  Notification  of  the  power  fail  condition  and 
duration  to  the  systea  console  device* 
o  Notification  of  the  power  fail  condition  end 
duration  to  tardet  control* 

—  o  Resumption  of  coaaunication  services* 

o  Extinduish  the  power  fail  laap/indicator  on 
the  processor  front  panel  and  the  status 
display  panel* 

—  -Power  fail  duration  dreater  than  the  radar  scan 

of  360  dedrees  (3*  6*  or  10  seconds). 

--  o  Notification  of  the  power  fail  condition  and 
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—  duration  to  the  system  console  device* 

—  o  Notification  of  the  power  fail  condition  and 

duration  to  target  control* 
o  Notification  of  the  power  fail  condition  and 
duration  to  all  users  -  local  and  remote* 
o  A  deletion  of  all  existing  (in-bound)  XY 
coordinate  messages* 

—  o  Resumption  of  communication  services* 

—  o  Extinguish  the  power  fail  laap/indicetor  on 

the  processor  front  panel  and  the  status 
display  panel* 

A  number  of  operator  commands  will  be  available  to 
— generate  free-form  text  messages*  test  messages  and 
— predefined  system  messages  as  well  as  initiate  and 
— terminate  specific  data  links*  A  number  of  commands 
— will  be  available  to  provide  information  as  to  data 
— links*  message  buffers  and  message  Queues  as  well  as 
— provide  a  single-step  execution  capability  of  following 
— the  reception  or  transmission  of  a  message* 

Each  message  will  have  dual  link  transmission  and 
— reception  but  upon  reception  only  one  valid  message 
— copy  is  reauired  for  intra-TSu-73  reouirements*  A 
— priority  message  structure  will  be  used  for  message 
— transmissions*  A  message  broadcast  capability  to 
— all  data  links  of  a  single  message  will  be  provided* 

The  various  radar  units  digitally  communicating 
— to  the  TSQ-73  are  capable  of  providing  a  360  degree 
— scan  every  three*  six  or  ten  seconds*  A  360  degree 
— scan  is  currently  divided  into  twenty  18  degree  sectors* 
— Variable  sector  sizes  are  desired  to  support  efficient 
—target  control  processing*  For  each  sector*  the  radar 
— sites  will  transmit  to  the  TSQ-73* 

-one  XY  coordinate  message  whether  a  target  is 

—  reported  or  not* 

-one  XY  coordinate  message  for  every  target 
reported* 

-a  maximum  of  96  XY  coordinate  messages  per 
360  degree  scan* 

— Approximate  XY  coordinate  message  size  is  20  bwtes  in- 
— eluding  header  and  checksum* 
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The  TSQ-73  free-form  text  messages*  radar  command 
— (reauests)  messages  are  a  variable  length  Message  but 
— will  have  a  minimum  of  20  bytes  and  a  maxi hub  of  64 
— bwtes  including  header  and  checksum.  A  maximum  of 
— one  free-form  message  per  display  console  operator 
—will  be  generated  per  three  seconds*  The  radar 
— units  are  capable  of  processing  free-form  text  messages 
— and  reouest  messages* 

An  analysis  of  the  ouanity*  size  and  type  of  message 
— transmitted  between  the  TSQ-73  and  radar  sites  is  as 
— follows* 

maximum  messages  per  scan  and  second* 

max*  msg*  *  max  XY  coor  msg  per  scan  x  max  active  data 
links  +  (free  form  msg  per  scan  x  max  display 
console  operators  x  2  (primary  and  redundant 
links)* 


min*  scan  time  (seconds) 
max.  msg  «  96  x  8  +  (1  x  8  x  2)  =  784 


3  3 

max*  msg*  per  scan  ■  784  msg* 
max  msg  per  second  ■  262  msg* 

NOTES  The  volume  of  text/cmd.  messages  from  radar  sites 
to  the  TSQ-73  is  insignificant  -  less  than  IX. 
maximum  characters  per  scan  and  second  per  data  link* 
max.  char*  ■  max*  XY  msg*  per  scan  x  char,  per  msg 
+  (text/cmd  msg*  per  scan  x  max.  display  console 
operators  x  char*  per  msg* 


min*  scan  time  (seconds) 
max*  char.  *  96  x  20  +  (1  x  8  x  64)  *  2432 


3  3 

max.  char*  per  scan  per  link  *  2432  char* 
max*  char,  per  second  per  link  =  811  char. 

—  The  radar  communication  subsystem  shall  be  blocked  and 
— deblocked  XY  coordinate  messages  to  and  from  the  TSQ-73 
— internal  message  size  for  intrasystems  transfer  with 
— target  control*  XY  coordinate  messages  shall  be  deblocked 
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— for  transmission  and  reception  to  and  from  the  radar 
— sites * 


twee  RADAR-COMMUNICATION _CAP AC I TIES -PERFORMANCE  is 
record 

— this  indicates  record  maximum  reouired  capacities  for 
— hardware/software  tradeoff  decisions* 

N0_ OF -DEGRESS _PER_SC AN t  constant } =360  * 
NO_OF_DEGREES_PER_SECTOR: constant: =181 
N0-0F_SECT0RS_PER-SCAN:=N0_0F-DEGREES_PER-SCAN/N0_0F_ 
DEGREES-PER-SECTOR } 

MAX-NO-OF-DISPLAY-CONSOLE-OPERATORS: constant: =8 
MAX-FREE-FORM-MSG-SIZE: constant: =64} 
AVG-FREE-FORM-MSG-SIZE: constant: =42} 
MIN-FREE-FORM-MSG-SIZE :  constant  *.  =20 } 

XY-COOR-MSG-SIZE: constant: =20} 
MAX-XY-COOR-MSG-PER-SCAN: constant: =96} 
MAX_FREE_FORM_MSG_PER_SEC: constant: *5. 334 
MAX_MSG_PER_SCAN : constant : =784 } 

MAX_MSG_PER_SEC : constant : =262 } 
MAX-CHAR-PER-SEC-PER-LINK: constant: =811} 
MAX-NO-OF-TASKS: constant :=20} 

--estimated  number  of  tasks  capacity  reouired  at  this  time* 
— (Does  not  include  I/O  handler  tasks).  A  more 
— accurate  number  will  be  provided  later  in  the  development 
— process ♦ 

ONE-SECOND : constant : =1 . 0 } 

INTERNAL _ TIMING-REQUIREMENT : constant : =0 . 010 } 

— internal  timind  reouirement  is  measured  in  milliseconds 
MI N_N0_0F_TASK-EXEC_PER_SEC := ONE-SECOND/ 

INTERNAL _ TIMING. REQUIREMENT } 

MIN_N0_0F-EXEC_PER_SEC_PER_TASK:=MIN_N0-0F_TASK_EXEC_ 

PER-SEC/MAX-NO.OF-TASKS} 

MAX-DATA-LINK: constant : =10 } 

MAX-ACTIVE-DATA-LINK: constant: =8} 

MAX_RADAR_SITES *  constant  *  =4  f 
— there  is  a  ratio  of  two  data  links  per  radar  site 
— plus  two  data  link  spares 
end  record} 
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type  SCAN_RATE  is  (SEC3»SEC6»SEC10) } 

type  BAUD-RATE  is  (B300?B600?B750» B1200? B1500rB2400?B4800?B9600> 

type  PROTOCOL  is  (TAD 1 1 _ B»ATDI _ ltMBDL) } 

type  ORIENTATION  is  (BIT_ORIENTED»CHAR_ORIENTED)  } 
type  TRANSMISSION  is  ( PT_T0.PT ? MULTI-DROP ) } 

type  LINE  is  (FULI _ DUPLEX»HALF_DUPLEX) } 

type  MSG-TYPE  is  (FREE_FORM_MSG»XY_COOR_MSG> } 
type  SYNC  is  (SYNCHR0N0US?ASYNCHR0N0US) } 
type  MODE  is  (PRIMARY 'REDUNDANT)  } 

type  RADAR-DATA-LINK-SPEC  is 
record 

DATA-LINK-BAUD-RATEJ BAUD-RATE5 

radar_protocol:protocol:=atdl_i} 

RADAR-ORIENTATION: orientation j=bit_oriented; 
radar-transmission: transmission :=pt-T0_pt; 

RADAR-LINE :LINEJ=FULL_DUPLEX} 

RADAR-SYNC t SYNC  * -ASYNCHRONOUS} 

radar_mode:mode} 

case  MSG-TYPE  is 
when  FREE_FORM_MSG=> 

RADAR_REQ_MSG_BUFFER* string  (1. . 

MAX_FREE_FORM_MSG_SIZE) } 
when  XY-COOR.MSG  => 

RADAR_REQ_MSG_BUFFERJ string  (1.. 

XY-COOR-MSG-SIZE) } 
end  case} 
end  record} 


PRIMARY-DATA-LINKiDATA-LINK-SPEC  range  1 « • MAX. RADAR-SITES } 
REDUNDANT-DATA-LINKJDATA-LINK-SPEC  range  1«  t MAX-RADAR-SITES } 

type  RADAR-CONFIGURATION  is 
record 

—  This  is  where  the  hardware  configuration  (if  any)  would 
— be  described  along  with  aininuin  execution  characteristics 
— for  radar  coaaunications .  The  record  would  include  the 
— following* 

—  CPU*  characteristics  (instruction  execution  speed?  type 
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instruction  mix) 

—  DATA  CHANNELS:  number  *  tape 

—  MEMORY:  size  £  tape 

—  INTERRUPTS:  number  &  tape 

—  CLOCKS*  TIMERS* DATE  DEVICES 

—  INPUT/OUTPUT  INTERFACES:  number  £  tapes 

—  REDUNDANCY  CHARACTERISTICS 

—  PERIPHERALS:  number*tapes  £  characteristics 

end  record* 


package  COMMUNICATION  SUPERVISOR  (4.1)  is 

— The  objectives  of  the  radar  communication  supervisor  are: 
— 1.  To  provide  a  controlling  interface  between  COMMAND  £ 
CONTROL *TARGET  CONTROL  and  REMOTE  COMMUNICATION. 

— 2.  To  provide  for  the  management  of  the  radar 
communication  itself. 


procedure  CONSUME  INTERNAL  MESSAGE  (4.1.1)$ 
procedure  INITIALIZE  RADAR  COMMUNICATION  (4*1.2)$ 
package  MANAGE  DATA  LINKS  (4.1.3)$ 
package  MANAGE  MESSAGES  (4.1.4)$ 

package  MANAGE  FAULT  DETECT I ON* CORRECT I ON  AND  REPORTING 
(4.1.5)  $ 

procedure  TERMINATE  REMOTE  COMMUNICATION  (4.1.6)$ 
procedure  PRODUCE  INTERNAL  MESSAGE  (4.1.7)$ 
end  COMMUNICATION  SUPERVISORS 


package  boda  COMMUNICATION  SUPERVISOR  (4.1)  is 

— Prior  to  initialization  of  RADAR  COMMUNICATION  it  is 
— assumed  that: 

— 1.  Preliminara  diagnostic  routines  have  been  performed  to 
identifa  and  report  various  hardware  faults. 
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-2.  Initiation  of  the  power-fail  monitor » intra-system 
(aessaie)  transfers  and  the  radar  communication 
supervisor  have  been  performed  by  COMMAND  AND  CONTROL* 
procedure  CONSUME  INTERNAL  MESSAGE  (4.1*1)  is 

begin 

loop 

while  INTERNAL  TIMING  REQUIREMENTS  loop 
if  MAILBOX  COUNT  <=0  then 
exit  loop » 

else  Set  INTERNAL  MESSAGE  * 

-utilizes  the  GET  task  of  INTRASYSTEM  TRANSFERS 
-validate  internal  message  originator 

if  COMMAND  AND  CONTROL  or  TARGET  CONTROL  INTERNAL 
MESSAGE  =  TRUE  then 

-validate  internal  message  type  and  Queue  message 
case  INTERNAL  MESSAGE  TYPE  is 
-message  type  *I'M  ALIVE*  is  handled  by  GET  TASK 

when  INITIALIZE  RADAR  COMM  >=  Queue  to 
INITIALIZE  RADAR  COMMUNICATION  (4.1.2) i 
when  MANAGE  DATA  LlNKS*>Queue  to  MANAGE  DATA 
LINKS  (4.1*3); 

when  MANAGE  MESSAGE=>oueue  to  MANAGE 
MESSAGES  (4.1.4)» 

when  MANAGE  FAULT  DETECTION » CORRECTION 
AND  REPORT I NG=>oueue  to  MANAGE  FAULT 
DETECTION > CORRECTION  AND  REPORTING  (4.1.5); 
when  TERMINATE  RADAR  COMMUNICATION«>Queue  to 
TERMINATE  RADAR  COMMUNICATION  (4.1.6); 
when  others=> 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  TYPE; 
Queue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7); 
end  case; 
else 

SET  ERROR  CODE  FOR  INVALID  INTERNAL  MESSAGE 

originator; 

Queue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7); 
end  if; 
end  if; 
end  loop; 
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DELAY  INTERNAL  TIMING  REQUIREMENTS  *  NUMBER  OF  TASKS? 
end  loop? 

end  CONSUME  INTERNAL  MESSAGE  (4.1.i>? 


procedure  INITIALIZE  RADAR  COMMUNICATION  (4.1.2)  is 


begin 

DEQUEUE  INTERNAL  MESSAGE  FROM  CONSUME  INTERNAL 
MESSAGE  (4.1.1)? 

use  package  HOUSEKEEPING  (4.1. 2.1)? 
if  POWER  FAIL  FLAG  and  AUTOMATIC  RESTART  FLAG  =  TRUE  then 
goto  MANAGE  FAULT  DETECTION ? CORRECTION 
AND  REPORTING  ( 4 . 1 . 5 ). AUTOMATIC  RESTART 
else 

CLEAR  MESSAGE  BUFFERS  (4.1. 2.1.1)? 

CLEAR  MESSAGE  QUEUES  (4. 1.2. 1.2)? 

CLEAR  MESSAGE  COUNTERS  (4. 1.2. 1.3)? 

CLEAR  TRANSACTION  LOG  INDICATOR 
(4.1. 2. 1.4)? 

CLEAR  POWER  FAIL  INDICATOR  <4. 1.2. 1.5)? 
end  if? 

procedure  INITIALIZE  COMMUNICATION  SUBSYSTEM  PARAMETERS 
(4.1.2. 2)  is 
begin 

priearg  and  redundant  line  adresses? 
association  of  routing  id?  data  link  adresses? 
baud  rate?  protocol  assignments?  and  transaction 
log  indicator* 

if  NON-DEFAULT  PARAMETER  FLAG  *  TRUE  then 
LOAD  NON-DEFAULT  PARAMETERS  (4.1.2. 2.1)? 
else 

LOAD  DEFAULT  PARAMETERS  (4. 1.2. 2. 2)? 
end  if? 

procedure  INITIALIZE  COMMUNICATION  TABLES  USING 
PARAMETERS  (4. 1.2. 2. 3)? 

procedure  INITIALIZE  DATA  LINK  TABLE  ( 4 . 1 . 2. 2 . 3 . 1 ) ? 
procedure  INITIALIZE  MESSAGE  TYPE  TABLE  (4. 1 .2. 2.3.2) ? 
procedure  SET  TRANSACTION  LOG  FLAG  (4. 1 .2. 2.3.3)  ? 
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6E  MESSAGES  (4 


GE  DATA  LINKS 
ICATION  (4*1.2 


package  MANAGE  DATA  LINKS  (4.1.3)  is 
procedure  MANAGE  DATA  LINK  STATUS  TABLE  (4. 1.3. 1)1 
procedure  MANAGE  PROTOCOLS  (4. 1.3.2)$ 
end  MANAGE  DATA  LINKS  (4.12.3)$ 


package  body  MANAGE  DATA  LINKS  (4.1.3)  IS 
—  THE  OBJECTIVE  OF  THE  MANAGE  DATA  LINKS  PACKAGE  IS  TO 
—MANAGE  THE  DATA  LINK  TABLEf  PROTOCOL  AND  THE 
—INITIALIZATION  AND  TERMINATION  OF  A  SINGLE  DATA  LINK, 
begin 

procedure  MANAGE  DATA  LINK  STATUS  TABLE  (4. 1.3.1)  is 
begin 

function  SEARCH  DATA  LINK  STATUS  TABLE  (4. 1.3. 1.1)$ 
function  INSERT  ENTRY  (4. 1.3. 1.2)$ 
function  DELETE  ENTRY  (4.1. 3.1.3)$ 

procedure  INITIATE  INITIALIZE  DATA  LINK  (4. 1.3. 1.4)$ 
procedure  INITIATE  TERMINATE  DATA  LINK  (4. 1.3. 1.5)$ 
end  MANAGE  DATA  LINK  STATUS  TABLE  (4. 1.3.1)$ 
procedure  MANAGE  PROTOCOLS  (4. 1.3. 2)  is 
—START  PROTOCOLS 
begin 

case  PROTOCOL  is 
when  ATDL-1  => 

initiate  ATDL-1  PROTOCOL  SUPERVISOR$ 
when  others  -> 

SET  ERROR  CODE  TO  INVALID  PROTOCOL$ 
aueue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7)$ 
end  case$ 

procedure  MONITOR  PROTOCOL  (4. 1.3. 2.1)$ 
procedure  INITIATE  TERMINATE  DATA  LINK  (4. 1.3. 2.2)$ 
procedure  REPORT  PROTOCOL  STATUS  (4. 1.3. 2.3)$ 
end  MANAGE  PROTOCOLS  (4. 1.3.2)$ 
end  MANAGE  DATA  LINKS  (4.1.3)$ 
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package  MANAGE  MESSAGES  (4.1*4)  is 

procedure  MESSAGE  SUPERVISOR  <4. 1*4.1)  I 
procedure  OUTGOING  MESSAGES  (4. 1.4. 2>$ 
procedure  INCOMING  MESSAGES  (4. 1.4.3)$ 
procedure  INTERNAL  MESSAGES  <4. 1.4. 4)) 
procedure  MANAGE  MESSAGE  BUFFERS  AND  QUEUES  (4. 1.4.5)$ 
end$ 

package  body  MANAGE  MESSAGES  (4.1.4)  is 
procedure  MESSAGE  SUPERVISOR  (4. 1.4.1)  is 


begin 

loop 

while  INTERNAL  TIMING  REQUIREMENT  <*0  loop 
if  MESSAGE  QUEUE  COUNT  >0  then 
DETERMINE  MESSAGE  ACTION  (4.1.4.1.1>$ 

SELECT  HIGHEST  PRIORITY  MESSAGE  (4. 1.4. 1.2)$ 

SELECT  HIGHEST  PRIORITY  MESSAGE 

WILL  BE  REPEATED  A  NUMBER  OF  TIMES  IN  REMOTE  AND 
RADAR  COMMUNICATIONS  AND  UOULD  PROBABLY  BE 
IMPLEMENTED  AS  PART  OF  THE  USERS'  RUNTIME  LIBRARY. 
TO  VALIDATE  MESSAGE  SUBTYPE 
case  MESSAGE  SUBTYPE 

when  POST  TRANSMISSION  MESSAGE  ACTION  => 

Queue  to  POST  TRANSMISSION  MESSAGE  ACTION 
(4. 1.4. 1.3) 

when  OUTGOING  MESSAGE  => 

Queue  to  OUTGOING  MESSAGE  (4. 1.4*2) 
when  INCOMING  MESSAGE  =  > 

Queue  to  INCOMING  MESSAGE  (4. 1.4. 3) 
when  INTERNAL  MESSAGE  =  > 

Queue  to  INTERNAL  MESSAGES  (4. 1.4. 4) 
when  others  => 

SET  ERROR  CODE  FOR  INVALID  MESSAGE  SUBTYPE$ 
QUEUE  TO  PRODUCE  INTERNAL  MESSAGE  (4.1.7)$ 
end  case$ 
else 

exit  1oop$ 
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end  if* 
end  loop* 

delaa  INTERNAL  TIMING  REQUIREMENT  *  NUMBER  OF  TASKS 
end  loop* 

procedure  POST  TRANSMISSION  MESSAGE  ACTION  <4,1. 4.1.3)  is 
begin 
loop 

while  INTERNAL  TIMING  REQUIREMENT  <=  loop 
if  POST  MESSAGE  QUEUE  >0  then 
function  SELECT  HIGHEST  PRIORITY  MESSAGE 
(4. 1.4.1. 3.1)) 

SELECT  HIGHEST  PRIORITY  MESSAGE 

WILL  BE  REPEATED  A  NUMBER  OF  TIMES  IN  REMOTE  AND 
RADAR  COMMUNICATIONS  AND  WOULD  PROBABLY  BE 
IMPLEMENTED  AS  PART  OF  THE  USERS'  RUNTIME  LIBRARY, 
procedure  POST  MESSAGE  STATUS  (4. 1 .4. 1 ,3 . 2) * 
if  TRANSACTION  LOG  FLAG  and  MESSAGE  ACKNOWLEDGEMENT 
REQUIRED  =  FALSE  then 

RELEASE  MESSAGE  BUFFER  < 4 . 1 . 4 . 1 . 3 . 2 . 1 ) * 
else  if  TRANSACTION  LOG  FLAG  AND  MESSAGE 
ACKNOWLEDGEMENT  REQUIRED  =  TRUE  then 
GET  MESSAGE  BUFFER  (4. 1 .4. 1 .3.2.2) * 

COPY  MESSAGE  TO  NEW  BUFFER  ( 4 . 1 . 4 . 1 . 3 . 2 . 3 ) * 
end  if* 

procedure  QUEUE  MESSAGE ( S )  TO  PRODUCE  INTERNAL 
MESSAGE  (4. 1,7)1 
end  if* 
end  loop* 

delay  INTERNAL  TIMING  REQUIREMENTS  *  NUMBER  OF  TASKS 
end  loop* 

end  POST  TRANSMISSION  MESSAGE  ACTION  (4. 1.4. 1.3)* 
end  MESSAGE  SUPERVISOR  (4. 1.4.1)* 


procedure  OUTGOING  MESSAGES  (4. 1.4. 2)  is 


begin 

loop 

while  INTERNAL  TIMING  REQUIREMENT  <=0  loop 
if  OUTGOING  MESSAGE  QUEUE  COUNT  >0  then 
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SELECT  HIGHEST  PRIORITY  MESSAGE  (4. 1,4. 2.1) 

SELECT  HIGHEST  PRIORITY  MESSAGE 
WILL  BE  REPEATED  A  NUMBER  OF  TIMES  IN  REMOTE 
AND  RADAR  COMMUNICATIONS  AND  WOULD  PROBABLY  BE 
IMPLEMENTED  AS  PART  OF  THE  USERS'  RUNTIME  LIBRARY, 
procedure  VALIDATE  OUTGOING  MESSAGE  (4, 1,4. 2. 2)  is 
begin 

function  MESSAGE  TYPE  TABLE  LOOKUP  (4. 1.4. 2,2.1 )} 
SEARCHES  MESSAGE  TYPE  TABLE  AND  RETURNS  MESSAGE 
TYPE  AND  DUPLICATION  CODES/IDS. 
if  MESSAGE  TYPE  NOT  OUTGOING  MESSAGE  TYPE  then 
SET  ERROR  CODE  FOR  INVALID  OUTGOING  MESSAGE} 

Queue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7)} 
end  if* 

function  DATA  TABLE  LOOKUPS  ( 4 . 1 .4 . 2.2.2) » 

SEARCHES  DATA  LINK  TABLE  BY  DESTINATION 
ID  AND  RETURNS  PROTOCOL  STATUS*  DATA  LINK 
AVAILABILITY  AND  PROTOCOL  MAILBOX, 
if  PROTOCOL  STATUS  INACTIVE  then 
SET  ERROR  CODE  FOR  INACTIVE  PROTOCOL  STATUS** 

Queue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7)} 
else  if  DATA  LINK  NOT  AVAILABLE  then 
SET  ERROR  CODE  FOR  INACTIVE  DATA  LINK} 

Queue  to  PRODUCE  INTERNAL  MESSAGE  (4.1.7)} 
end  if} 

procedure  REPLICATE  MESSAGE  FOR  MULTIPLE  MESSAGES 
(4. 1.4. 2. 2. 3)  is 
bedin 

if  MULTIPLE  MESSAGES  then 
for  I  IN  I.... NUMBER  OF  MESSAGES  -  1  loop 
GET  MESSAGE  BUFFER  ( 4 . 1 . 4 .2 . 2 . 3, 1 ) } 

COPY  MESSAGE  TO  NEW  BUFFER 
(4. 1.4. 2. 2.3.2) } 
end  loop} 
end  if} 

end  REPLICATE  MESSAGE  FOR  MULTIPLE  MESSAGES 
(4. 1.4. 2. 2. 3) } 

procedure  QUEUE  MESSAGE(S)  TO  PRODUCE  INTERNAL 
MESSAGE  (4.1.7) 

end  VALIDATE  OUTGOING  MESSAGE  (4. 1.4. 2. 2)} 
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end  if» 
end  loop* 

delea  INTERNAL  TIMING  REQUIREMENT  *  NUMBER  OF  TASKS 
end  loop* 

end  OUTGOING  MESSAGES  (4. 1.4. 2>! 

procedure  INCOMING  MESSAGES  (4. 1.4.3)  is 
bedin 

end  INCOMING  MESSAGES  (4. 1.4. 3)* 

procedure  INTERNAL  MESSAGES  (4. 1.4* 4)  is 
bed  in 

end  INTERNAL  MESSAGES  (4.1. 4.4)1 

procedure  MANAGE  MESSAGE  BUFFERS  AND  QUEUES  (4. 1.4. 5)  is 
bed  in 

end  MANAGE  MESSAGE  BUFFERS  AND  QUEUES  (4. 1.4.5) 
end  MANAGE  MESSAGES  (4.1.4) * 


packade  MANAGE  FAULT  DETECTION.  CORRECTION  AND  REPORTING 
(4.1.5)  is 


—AUTOMATIC  RESTART  WOULD  APPEAR  IN  THIS  AREA 
procedure  IDENTIFY  FAULTS  (4. 1.5.1)  is 
bedin 

procedure  HARDWARE  FAULTS  (4.1. 5.1.1)* 
procedure  SOFTWARE  FAULTS  <4. 1.5. 1.2)1 
end  IDENTIFY  FAULTS  (4. 1.5.1)* 
procedure  UPDATE  ERROR  COUNTERS  (4. 1.5. 2)* 
procedure  ATTEMPT  CORRECTIVE  ACTION  (4. 1.5. 3)* 
procedure  REPORT  FAULTS  (4. 1.5. 4)* 
end  MANAGE  FAULT  DETECTION.  CORRECTION  AND  REPORTING 
(4.1.5) * 

packade  body  MANAGE  FAULT  DETECTION.  CORRECTION  AND 
REPORTING  (4.1.5)  is 

end  MANAGE  FAULT  DETECTION.  CORRECTION  AND  REPORTING 
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(4.1.5) i 


procedure  TERMINATE  REMOTE  COMMUNICATION  (4.1.6)  is 
begin 

procedure  BUILD  TERMINATION  MESSAGE  (4. 1.6.1); 
procedure  START  TERMINATE  DATA  LINK  (4. 1.6.2); 
procedure  UPDATE  DATA  LINK  STATUS  TABLE  (4. 1.6.3); 
procedure  ABORT  DATA  LINK  MANAGER  (4. 1.6. 4); 
procedure  ABORT  MESSAGE  MANAGER  (4. 1.6. 5); 
procedure  UPDATE  TRANSACTION  LOG  (4. 1.6.6); 
end  TERMINATE  REMOTE  COMMUNICATIONS  (4.1.6); 


procedure  PRODUCE  INTERNAL  MESSAGE  (4.1.7)  IS 
begin 
loop 

while  INTERNAL  TIMING  REQUIREMENT  >0  loop 
if  PRODUCE  INTERNAL  MESSAGE  COUNT  <=0  then 
exit  loop; 

else  SELECT  HIGHEST  PRIORITY  MESSAGE  (4. 1.7.1); 

SELECT  HIGHEST  PRIORITY  MESSAGE 
WILL  BE  REPEATED  A  NUMBER  OF  TIMES  IN  REMOTE 
AND  RADAR  COMMUNICATIONS  AND  WOULD  PROBABLY  BE 
IMPLEMENTED  AS  PART  OF  THE  USERS'  RUNTIME  LIBRARY. 

procedure  DEQUEUE  MESSAGE  FROM  PRODUCE  INTERNAL  MESSAGE 
QUEUE  (4. 1.7. 2); 

—  VALIDATE  INTERNAL  MAILBOX  ID  AND  PUT  MESSAGE 

case  INTERNAL  MAILBOX  ID  is 
when  COMMAND  AND  CONTROL  ID  «>  PUT 
MESSAGE  TO  COMMAND  AND  CONTROL  MAILBOX; 

—  UTILIZE  THE  PUT  TASK  OF  INTRASYSTEM  TRANSFERS 

when  TARGET  CONTROL  ID  =>  PUT 
MESSAGE  TO  TARGET  CONTROL  MAILBOX; 
when  REMOTE  COMMUNICATIONS  ID  *>  PUT 
MESSAGE  TO  REMOTE  COMMUNICATIONS  MAILBOX; 
when  others  => 

SET  ERROR  CODE  FOR  INVALID  INTERNAL  MAILBOX  ID; 

PUT  MESSAGE  TO  COMMAND  AND  CONTROL  MAILBOX; 
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end  case? 
end  if} 
end  loop} 

delay  INTERNAL  TIMING  DELAY  *  NUMBER  OF  TASKS} 
end  loop} 

end  PRODUCE  INTERNAL  MESSAGE  <4.1.7)} 
end  COMMUNICATION  SUPERVISOR  (4.1)} 


package  INTRASYSTEM  TRANSFER  <4. 2)  is 

— The  objective  of  the  INTRASYSTEM  TRANSFER  subentity  is  to 
— provide  facilities  which  allow  message  flow  between  the 
—RADAR  COMMUNICATIONS  and  the  COMMAND  l  CONTROL  and  other 
— processors  as  well  as  support  message  flow  within  the  RADAR 
— COMMUNICATIONS.  To  insure  message  flow  integrity* 

— INTRASYSTEM  TRANSFERS  will  employ  mailbox  concepts  with 
— semaphore  counters  and  message  time  stamps  to  identify 
— potential  bottlenecks  and  provide  periodic  status  reports  as 
— needed.  INTRASYSTEM  TRANSFER  is  started  and  terminated  by 
—COMMAND  &  CONTROL. 

—The  INTRASYSTEM  TRANSFER  package  is  intended  to  operate 
— concurrently  with  various  other  operations  and  is  itself 
—comprised  of  MESSAGE  POSTING  TIMER*  GET  INTRASYSTEM 
—TRANSFER  and  PUT  INTRASYSTEM  TRANSFER. 

The  following  descriptions  assume  that  COMMAND  & 

— CONTROL  has  generic  mailbox  box  features  which  utilize 
— the  semaphore  concept.  The  initialization  function  of 
— COMMAND  &  CONTROL  will  initialize  the  proper  number  and 
— type  of  mailboxes  necessary  to  implement  this  activity. 

Mailboxes  are  producer-consumer  points*  the  number  of 
— which  is  determined  at  initialization  time  by  the  number  of 
— protocols • 

procedure  GET  INTRASYSTEM  TRANSFERS  (4.2.1)} 
procedure  PUT  INTRASYSTEM  TRANSFERS  (4.2.2)} 

Procedure  MESSAGE  POSTING  TIMER  (4.2.3)} 
end  INTRASYSTEM  TRANSFERS  (4.2)} 

package  body  INTRASYSTEM  COMMUNICATIONS  (4.2)  is 
procedure  GET  INTRASYSTEM  TRANSFER  (4.2.1)  is 
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-The  get  end  put  features  of  INTRASYSTEM  TRANSFER 
-  may  be  implemented  in  two  ways.  The  first  method 
-is  to  have  each  mailbox  employ  its  own  set  and  put 
-tasks.  The  second  method  is  separate  procedures 
-for  set  and  put  with  multiple  mailboxes  -  a  logical 
-multiplexer.  This  is  a  concurrent  task, 
begin 
loop 

while  INTERNAL  TIMING  REQUIREMENT  >0  loop 
if  MAILBOX  COUNT  <0  then 
exit  loop. 

else  for  I  IN  I... NUMBER  OF  MAILBOXES  loop 
TIMEOUT  FLAG ( I )  =  FALSE ? 
end  loop? 
end  if? 
loop 

for  I  IN  I... NUMBER  OF  MAILBOXES  loop 
if  GET  MESSAGE  BUFFER  =  EMPTY  then 
if  TIMEOUT  FLAG  (I)  TRUE  then 
ISSUE  PRODUCER  ERROR? 

TIMEOUT  FLAG  (I)  =  FALSE? 
else 

TIMEOUT  FLAG  (I)  *  TRUE? 
end  if? 
else 

TIMEOUT  FLAG  <I>  =  FALSE? 
get  MESSAGE  FROM  BUFFER  <I>? 

UPDATE  TIME  STAMP  QUEUE  <I>? 
determine  message  type 

if  MESSAGE  ■  'I'M  ALIVE'  then 
DISCARD  MESSAGE? 
else 

MESSAGE  AVAILABLE  FOR  PROCESSING? 
end  if? 
end  if? 
end  loop? 

delay  INTERNAL  TIMING  REQUIREMENT  *  NUMBER  OF  TASKS 
end  loop? 

end  GET  INTRASYSTEM  TRANSFER  (4.2.1)? 
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procedure  PUT  INTRASYSTEM  TRANSFER  (4.2.2)  is 
-The  Set  end  put  features  of  the  INTRASYSTEM  TRANSFER 
-maw  be  implemented  in  two  ways.  The  first  Method 
-is  to  have  each  mailbox  employ  its  own  Set  and  put 
-procedures . 

-The  second  method  is  separate  procedures  for  set  and  put  with 
-multiple  mailboxes  -  a  loSical  multiplexer, 
procedure  TEST  BUFFER  (DESTINATION)  is 
besin 
loop 

while  INTERNAL  TIMING  REQUIREMENT  >  0  loop 
if  MAILBOX  COUNT  <  0  then 
exit  loop? 

elsif  DESTINATION  BUFFER  =  NOT  EMPTY  then 
if  DESTINATION  TIMEOUT  FLAG  =  TRUE  then 
ISSUE  CONSUMER  ERROR ? 

DESTINATION  TIMEOUT  FLAG  =  FALSE ? 
else 

DESTINATION  TIMEOUT  FLAG  =  TRUE? 
end  if? 
else 

PUT  MESSAGE  IN  DESTINATION  MAILBOX? 

DESTINATION  TIMEOUT  FLAG  =  FALSE? 
end  if? 
end  loop? 
end  TEST  BUFFER? 
loop 

accept  MESSAGE  (MESSAGE)? 

DETERMINE  DESTINATION?  —FROM  MESSAGE  CONTENT 
case  DESTINATION  is 

when  COMMAND  CONTROL  or  TARGET  CONTROL  or 
RADAR  COMMUNICATION  -  > 

TEST  BUFFER  (COMMAND  AND  CONTROL)? 
when  COMMUNICATION  SUPERVISOR  =  > 

TEST  BUFFER  (COMMUNICATION  SUPERVISOR)? 
when  TADIL-B  PROTOCOL  *> 

TEST  BUFFER  (TADIL-B  PROTOCOL)? 
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when  ATDL-1  PROTOCOL  => 

TEST  BUFFER  (ATDL-1  PROTOCOL)} 
when  MBDL  PROTOCOL  => 

TEST  BUFFER  <  MBDL  PROTOCOL)} 
end  esse! 

delay  INTERNAL  TIMING  REQUIREMENT} 
end  loop} 

nd  put  INTRASYSTEM  TRANSFER  (4.2.2)} 

rocedure  MESSAGE  POSTING  TIMER  (4.2.3)  is 
-The  objectives  of  the  MESSAGE  POSTING  TIMER 
-are  to  periodically  generate  'I'M  ALIVE'  Messages 
-if  no  other  Message  activity  has  occurred  in 
-any  particular  area  for  a  period  eaual  to  or 
-greater  than  the  internal  tining  reauirement 
-and  to  insure  that  Messages  generated  by  the 
-producing  tasks  are  actually  being  consuaed. 

-In  the  case  that  generated  Messages  are  not 
-being  consuaed  the  Mezc'ge  posting  tiger  alerts 
-the  message  producing  task  and  the  operator, 
procedure  CONSUMER  TIMER  (4. 2. 3.1)  is 
begin 
loop 

for  I  IN  I... NUMBER  OF  MAILBOXES  loop 

if  GET  MESSAGE  BUFFER(I)  =  NOT  EMPTY  then 
if  CURRENT  TIME-TIME  STAMP(I)  > 

INTERNAL  TIMING  REQUIREMENT  then 
ISSUE  TIMEOUT  ERROR ( I ) } 
elsif  SEMAPHORE  COUNTER ( I ) >MAX  MESSAGES/SEC 
then 

ISSUE  SEMAPHORE  ERROR ( I )  } 
end  if} 
end  if} 
end  loop} 

delay  INTERNAL  TIMING  REQUIREMENT} 
end  loop} 

end  CONSUMER  TIMER  (4, 2. 3.1)} 

procedure  PRODUCER  TIMER  (4. 2. 3. 2)  is 
begin 


D-85 


loop 


for  I  IN  I. .  . NUMBER  OF  MAILBOXES  loop 
if  PUT  MESSAGE  BUFFER(I)  =  EMPTY  then 
if  CURRENT  TIME  -  TIME  STAMP> 

INTERNAL  TIMING  REQUIREMENT  then 
BUILD  'I'M  ALIVE'  MESSAGE 5 
put  'I'M  ALIVE'  MESSAGE  IN  MAILB0X(I>5 
end  iff 
elsif 

SEMAPHORE  COUNTER ( I ) >MAX  MESSAGES/SEC 
then 

ISSUE  SEMAPHORE  ERROR 5 
end  iff 
end  loop  5 

delay  INTERNAL  TIMING  REQUIREMENT  5 
end  loopf 

end  PRODUCER  TIMER  (4.2. 3.2)5 

— Additional  details  (Queue  management f  buffer  management f 
— internal  routing  table,  etc.)*  are  not  included  due  to 
— project  schedule  restrictions. 

end  MESSAGE  POSTING  TIMER  (4.2.3)  5 
end  INTRASYSTEM  TRANSFERS  (4.2)5 


Package  COMMUNICATION  PROTOCOL  (4.3)  is 

—  The  objective  of  the  COMMUNICATION  PROTOCOL  package  is  to 
— handle  the  physical  level  of  the  transmission  and 

— reception  of  digital  messages  according  to  the  predefined 
— military  protocol  ATDL-1. 

—  The  COMMUNICATION  PROTOCOL  package  is  initiated  and 

—  The  protocol  used  by  the  COMMUNICATION  PROTOCOL  package 
--is  ATDL-lf  which  cannot  be  discussed  further  due  to 
--it  classification.  However,  it  will  be  handled  by  the 
— following  procedures. 

procedure  CONSUME  COMM  SUPERVISOR  MESSAGE  (4. 3, 1)5 
procedure  INITIALIZE  DATA  LINK  (4. 3. 2)5 
procedure  TRANSMIT  MESSAGE  (4.3.3)  5 
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procedure  RECEIVE  MESSAGE  (4.3.4 )} 
procedure  PROTOCOL  UTILITIES  (4.3.5)} 
procedure  TERMINATE  DATA  LINK  (4.3.6)} 
procedure  COMM  SUPERVISOR  MESSAGE  PRODUCT  (4.3.7) 
end  COMMUNICATION  PROTOCOLS  (4.3) 
end  RADAR  COMMUNICATION  (4.0)} 
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ACK_  (FLOW): 


-  ACKNOWLEDGEMENT; 

AFFIRM-ACK  i 
NEG.ACK ! 

ADD-  (FLOW): 

"TRACK  RECORD  TO  BE  ADDED  TO  TRACK  STORAGE  FILE" 
TRACK-REC ! 

AFFIRM-ACK  <  ELEMENT ) : 

-  ACKNOWLEDGEMENT  INDICATOR;  ! 

ALTITUDE-  (ELEMENT): 

-  RANGE  1000-2000  FEET; 

{DIGIT}  ! 

ALTITUDE-GATE  (FLOW): 

-  INTEGER  RANGE  LOWER  ALT  GATE. .  UPPER  ALT  GATE; 

-  CLASSIFIED; 

{DIGIT} f 

ASSOCIATION-COUNT  (ELEMENT): 

-  INTEGER  RANGE  1.  .  15; 

"HOW  MANY  OTHER  TARGETS  THAT  HAVE  BEEN  ASSOCIATED 
WITH  A  CERTAIN  TARGET" 

(DIGIT) ! 

(DIGIT* 

DIGIT) ! 

ASSOC-DATA  (FLOW): 

TRACK-NO  & 

CONSECUTIVE-HIT  * 

CONSECUTIVE-MISS! 

AZIMUTH.  (ELEMENT): 

-  MEASURED  IN  DEGREES; 


CDIGIT3 ! 


F-l 


CC-TC-MSG  (FLOW): 


(TACTICAL-REPORT  & 
ECM-REPORT  & 
SWITCH-ACTION-DATA  & 
MODE-  & 

TARGET-REPORT  <c 
INITIALIZATION-MSG)  ! 


CONSECUTIVE-HIT  (ELEMENT): 

-  CONSEC  ASSOCIATION  HITS) 

-  INTEGER  FROM  1.  .  15; 

DIGIT ! 

2CDIGIT>2! 


CONSECUTIVE-MISS  (ELEMENT): 

-  CONSEC  ASSOCIATION  MISSES; 

(DIGIT) ! 

(DIGIT  & 

DIGIT)  ! 


CONSECUTIVE-OUTERGATE-COUNT  ( ELEMENT ) : 

"NUMBER  OF  CONSECUTIVE  OUTERGATE  COUNTS" 

(DIGIT) ! 

CORRELATION. COUNT  (FLOW): 

( R-GATE-CNT ! 

OUTERGATE-COUNT ! 

INNERGATE-COUNT! 

CONSECUTIVE-OUTERGATE-COUNT)  ! 

CURRENT_ASSOCIATED_REPORT_FILE  ( FLOW ) : 

REPORT-TO.TRACK-PAIR ! 

CURRENT-TIME  (FLOW): 

TIME-! 

DELETE-  (FLOW): 

"TRACK  RECORD  TO  BE  DELETED  FROM  TRACK  STORAGE  FILE" 
TRACK-REC  ! 

F-2 


DEVIATION-VECTOR  (FLOW): 


VECTOR- ! 


DISPLAY-MSG  (FLOW): 

THREAT-PRIORITY! 
OPERATOR_ALERT ! 
HOLD-FIRE-MSG! 


DROP-DATA  (FLOW). 


DELETE- ( 


ECM-DAT  A  (FLOW): 

JAM_STROBE_DATA ! 
CHAFF_DAT  A ! 


ECM-REPORT  (FLOW): 

TRACK.NO  & 
ECM-DATA ! 


IFF-ALERT  (ELEMENT): 

"IF  MODE  3/A  CODE  OF  ASSOCIATION  REPORT  CONTAINS  AN 
AIRCRAFT, COMMUNICATION.  !  HIJACK  EMERGENCY  CODE" 

OIGIT  i>. 

DIGIT! 


IFF_DATA  (FLOW): 

VALID-COOE! 
INVALID-CODE ! 


IFF_RECORD  (FLOW): 

IFF_0AT  A ! 


INDEX.  (ELEMENT): 

-  USED  TO  INDICATE  DEGREE  OF  MANEUVERABILITY  OF 
TARGET; 

1! 

2! 

3! 

4  ! 

5! 
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INITIALIZATION-DATA  (FLOW); 


TARGET-CONTROL-PARAMETER  I 
TARGET-CONTROL-ALGORITHM ! 


INITIALIZATION-MSG  (FLOW): 

ALGORITHM-INDICATOR  * 
INITIALIZATION-DATA ! 


INITIAL-TRACK-RECORD  (FLOW):  ! 

INNERGATE-COUNT  (ELEMENT): 

-  INTEGER  RANGE  0. . 15; 

DIGIT* 

2-£DIGIT>2  ’ 


INVALID-CODE  (ELEMENT): 

-  UNFRIENDLY;  ! 


LOCAL_RADAR_BUFF  (FLOW): 

REPORT-NO  * 
SECTOR-NO  * 
RANGE-  & 
AZIMUTH-  * 
CIFF-DATA]  * 

C ALTITUDE- ]  * 
TRACK-REC ! 


MODE-  (FLOW). 

TRACKING-MODE  & 

BEACON-INTERROGATION  & 

TRACK-INITIATION! 

NEGATIVE-ACK  (ELEMENT); 

-  LACK  OF  ACKNOWLEDGEMENT  INDICATOR;  ! 

NON_ASSOC_TGT_REP  (FLOW): 

"TARGET  REPORT  NOT  ASSOCIATED  WITH  ANY  CORRELATED 
REPORT" 


TARGET-REPORT ! 
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NON- ASSOC -TRACK  (FLOW): 


TRACK-NO  ! 

NON_COR*REL-TGT_REP  (FLOW): 

"TARGET  REPORT  NOT  CORRELATED  WITH  ANY  OTHER  TARGET 
REPORT" 

TARGET-REPORT ! 

NON-CORREL-TRACK  (FLOW): 

TRACK-NO ! 

NON_MATCHING_TGT_REP  (FLOW): 

NON_ASSOC_TCT_REP  i 
NON-CORREl _ TCT-REP ! 

NON-MATCHING-TRACK  (FLOW): 

NON-ASSOC-TRACK  *, 

NON-CORREL-TRACK ! 

OLD-ALTITUDE  (FLOW): 

-  ALTITUDE  PRIOR  TO  SMOOTHING; 

ALTITUDE- ! 

OLD-INDEX  (FLOW): 

-  INDEX  PRIOR  TO  PROCESSING  BY  2.  2.  3.  4; 

INDEX. ! 

OLD-POSITION  (FLOW): 

-  POSITION  PRIOR  TO  SMOOTHING: 

POSITION- ! 

OLD-VELOCITY  (FLOW): 

-  VELOCITY  PRIOR  TO  SMOOTHING; 

VELOCITY. ! 


OPERATOR-ALERT  (FLOW): 
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MERGE-ALERT ! 

ENGAGEMENT-ALERT ! 

IFF-ALERT ! 

OUTERGATE-COUNT  (ELEMENT): 

-  INTEGER  RANGE  0.  .  15; 

DIGIT  it 
2CDIGIT>2! 

POOR-TRACKING-STATUS-INDICATOR  (FLOW) : 

-  STANDARD  MESSAGE  FORMAT;  ! 

POSITION-  (FLOW): 

VECTOR.  ! 

PREDICTED-POSITION  (FLOW): 

-  POSITION  AFTER  PREDICTION  2.  2.  3.  4; 
POSITION.! 

PREDICTED-VELOCITY  (FLOW): 

VELOCITY- 1 

RADAR-REPORT  (FLOW): 

TARGET-REPORT ! 

RADAR-REPORT-BUFFER  (FLuW): 

{RADAR -REPORT}  ! 

REMOTE_COMM_MSG  (FLOW): 

PRIMARY-ASSIGN  it 
SECONDARY-ASSIGN ! 

COMMAND-MSG ! 

REMOTE-COMM-REPORT  (FLOW): 

TRACK-NO  it 

POSITION  WITH  REMOTE  CENTER  & 
IFF-DATA  ! 


REMQTE-RADAR-BUFF  (FLOW): 


REPORT_NO  & 
SECTOR-NO  & 
RANGE.  ». 
AZIMUTH-  & 
CIFF-DATA]  & 

C ALTITUDE- 3  * 
TRACK-REC ! 


REMOTE_TRACK_DATA  (FLOW): 

TRACK-NO  It 

POSITION  WITH  LOCAL  SYSTEM  COORDINATE  CENTER  & 
IFF-DATA ' 


REPORT-ALTITUDE  (FLOW)- 
ALTITUDE-! 


REPORT-NO  (ELEMENT): 

-  INTEGER  RANGE  1.  .  NO  OF  TARGETS  DETECTED; 

{DIGIT!  CORRELATION-SCORE  (ELEMENT):  -INTEGER  RANGE 
0.  .  15;  -CDIGIT>  ! 


REPORT_TO_TRACK_PAIR  (FLOW): 

REPORT-NO  & 

TRACK-NO ! 

RESULT.  (FLOW); 

INVALID-CODE  ! 
VALID-CODE ! 

R-GATE  (ELEMENT): 

-  BOOLEAN; 

'TRUE'  ! 

'FALSE' ! 

R-GATE-CNT  (ELEMENT): 

-  INTEGER  RANGE  1.  .  15; 

DIGIT  l 
2{DIGIT>2! 


SCAN-TIME  (FLOW): 
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-  DEPENDS  ON  RADAR  TYPE; 

-  DETERMINED  AT  INITIALIZATION; 

-  GIVEN  IN  SECONDS; 

'  3 '  ! 

'  6 '  ' 

'10'  ! 


SECTOR.NO  (ELEMENT): 

-  INTEGER  RANGE  i.  .  20; 

-  SECTOR  IS  IS  DEGREES  IN  SIZE; 

-  20  SECTORS; 

(  '0'  : 

'1 '  ! 

'2'  >  & 

(DIGIT ) ! 


SMOOTHED- ALTITUDE  (FLOW): 

-  ALTITUDE  AFTER  SMOOTHING  2.  2.  3.  3 
ALTITUDE-! 


SMOOTHED-DATA  (FLOW): 

SMOOTHED-POSITION  It 
SMOOTHED-VELOCITY  It 
[SMOOTHED -ALTITUDE  3  It 
[SMOOTHING-INDEX]  It 
TIME_OF_LAST_SMOOTHING ! 


SMOOTHED-POSITION  (FLOW): 
POSITION-! 


SMOOTHED-VELOCITY  (FLOW): 
VELOCITY- ! 


SMOOTHING-CONSTANTS  (FLOW). 

SMOOTH-FOSITION-CONSTANT ! 
SMOOTH-VELOCITY-CONSTANT  ! 

SMOOTHING_CONSTANT_TABLE  (FILE): 

"TABLE  OF  SMOOTHING  CONSTANTS" 


{SMOOTHING-CONSTANTS}  ! 


SMOOTHING-INDEX  (ELEMENT): 


-  INTEGER  RANGE  1.  .  5i 


i 

'2'  i 
'3'  : 
'4 ' : 
'5  '  ! 


SMOOTH-POSITION-CONSTANT  (ELEMENT)  : 

( ' 7/16  '  ! 

'9/16'  : 

'11/16  '  ! 

'13/16'  ! 

'15/16  '  )  ! 


SMOOTH-VELOCITY-CONSTANT  (ELEMENT)  : 

( '1/16'  ! 

'3/16  '  ! 

'5/16'  ! 

'7/16'  ! 

'9/16'  )  ! 


STATUS-  (FLOW): 

-  TRACK  STATUS:  ! 


SWITCH-ACTION-DATA  (FLOW) 

TRACK-DATA ! 

ECM-DAT  A ! 

TACTICAL-DATA! 

OPERATOR-REQUESTS! 


SYSTEM-PARAMETER-FILE  (FILE): 

SMOOTHING-CONSTANTS  & 
SYS-MODE  *< 

SCAN-TIME! 


SYS-MODE  (FLOW): 
MODE- ! 


TACTICAL-DATA  (FLOW). 


(TRACK-NO  *< 
THREAT-PRIORITY  & 
SLACK-TIME) ! 
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TACTICAL-REPORT  (FLOW): 


TAC-RPT-HEADER  & 
TAC-RPT-BODY ! 


TARGET-CONTROL-DATA  (FLOW): 

SWITCH_ACTION_DATA  ! 
TRACK-DATA  ! 

ECM-DATA  ! 
TACTICAL-DATA ! 


TARGET_CONTROL_DATA_BASE  < FILE  )  : 

(TRACK_STORAGE_FILE  & 
DEFENDED-POINT-FILE  & 
FU-STATUS-FILE  & 
SYSTEM-PARAMETER-FILE  & 
JAM-STROBE-FILE  & 
SMOOTHING-CONSTANT-TABLE  it 
TRACK-PARAMETER-FILE  & 
TRACK-ALGORITHM-FILE  & 
THREAT-PARAMETER-FILE  & 
WEAPON-ASGN  & 
THREAT-ALGORITHM-FILE  & 
WEAPON_ASSIGN_ALGORITHM_FILE  & 
ALGORITHM-LIBRARY  & 
SAFE-CORRIDOR_FILE  & 
CLUTTER_MAP_FILE) ! 


TARGET-MSG  (FLOW): 

(INITIALIZATION-MSG  ! 
TARGET-REPORT  ! 
ECM-REPORT  ! 
TACTICAL-REPORT ! 
MODE-! 

SECTOR-PULSE! 
NORTH-SECTOR-PULSE)  ! 


TARGET-REPORT  (FLOW): 

LOCAL_RADAR_BUFF  & 
REMOTE_RADAR_BUFF  V. 
REMOTE-COMM-REPORT ! 


TC-CC-MSG  (FLOW): 

(ACK_  l 

TARGET-CONTROL-DATA  & 
DISF’LAY-MSG  4 
TC _REM -COMM _MSG  >  ! 
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TCT-REP-BUFF  (FLOW): 


REPORT -TO -TRACK _PAIR  & 
TRACK -QUALITY  & 

NON- MATCH INC -TGT-REP  & 
ASSOC-DATA ! 


THREAT .PRIORITY  (ELEMENT): 

-  HIGHEST  TO  LOWEST  PRIORITY  OF  THREAT; 
(DIGIT) ! 


TIME-  (ELEMENT): 


-  HH  MM  SS  SS; 

-  HOURS,  MINUTES,  SECONDS  AND  HUNDREDTHS  OF  SECONDS; 


(0  ! 

1 ! 

2)  & 
DIGIT  & 
(0! 

1  i 
2! 

3! 

4 : 

5)  % 
DIGIT  %. 
(0 : 

1! 

2  i 
3! 

4! 


5)  & 
DIGIT  % 
' .  '  & 
DIGIT  V 
DIGIT! 


TIME_FROM_LAST_SMOOTHING  (FLOW): 
TIME.! 


TIME-OF-LAST-SMOOTHING  (FLOW) 
TIME- ! 

TRACK-ALTITUDE  (FLOW): 
ALTITUDE-! 

TRACK-DATA  (FLOW). 


(STATUS-  it 
TRACK-NO  i. 

PREDICTED-POSITION  & 
PREDICTED-VELOCITY  it 
ALTITUDE-  i 
OUTERCATE-COUNT  $ 
INNERGATE-COUNT  & 
ASSOCIATION-COUNT  & 
SMOOTHING-INDEX  & 
SMOOTHED-ALTITUDE  It 
SMOOTHED-VELOCITY  it 
SMOOTHED-POSITION  It 
TIME_OF_LAST_SMOOTHING  it 
DEVIATION-VECTOR) ! 


TRACK-NO  (ELEMENT): 

-  INTEGER  RANGE  1. .  NO  OF  TRACKS  IN  SYSTEM  CAPACITY; 

-  CLASSIFIED; 

<DIGIT> ! 


TRACK-QUALITY  (FLOW): 

-  INTEGER  RANGE  0.  .  7; 

(0  ! 

1! 

2! 

3! 

4  ! 

5  I 

6  ! 

7)  ! 


TRACK-REC  (FLOW). 

TRACK-DATA ! 


TRACK. STORAGE-FILE  (FILE): 
{TRACK-DATA}  ! 

UPDATED.TRACK.REC  (FLOW): 

ADD-  ! 

DELETE-! 


UPDATE-DATA  (FLOW): 

UPDATED-TRACK-REC  ! 
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VALID-CODE  (ELEMENT): 


-  FRIENDLY;  ! 


VECTOR-  (FLOW): 

X-COORD  A 
Y-COORD ! 


VELOCITY-  (ELEMENT):  ! 


X-COORD  (ELEMENT): 

{DIGIT}*. 
{DIGIT}  ! 


Y.COORD  (ELEMENT): 

{DIGIT}*. 

"A 

{DIGIT} ! 


SMOOTHING.  (PROCESS  2.  2.  3.  3): 

FOR  EACH  REPORT-TO-TRACK-PAIR  LOOP: 
DET_SMOOTHING_INDEX; 
SMOOTH-POSITION; 

SMOOTH-VELOCITY; 

IF  REPORT-ALTITUDE  IS  PRESENT: 

SMOOTH-ALTITUDE. 

EN  IF; 

UPDATE  TRACK-STORAGE-FILE. 

OOP! 


SMOOTH-POSTIION  (PROCESS  2.  2.  3.  3.1): 

FROM  TRACK  STORAGE  FILE  GET: 

OLD-POSITION; 

DEVIATION-VECTOR. 

FROM  SMOOTHING-CONSTANT-TABLE  GET: 
SMOOTH-POSITION-CONSTANT. 

SMOOTH-POSITION  *=  OLD-POSITION  +  SMOOTH-POSITION-CONSTANT 
*  DEVIATION-VECTOR! 


SMOOTH-VELOCITY  (PROCESS  2.  2.  3.  3.  2): 
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OLD-VELOCITY ; 

DEVIATION-VECTOR. 

FROM  SMOOTHING  CONSTANT  GET: 

SMOOTH. VELOCITY-CONSTANT. 

SMOOTHED-VELOCITY  =  OLD-VELOCITY  +  <, 

SMOOTH-VELOCITY-CONSTANT  /  SCAN-TIME)  * 
DEVIATION-VECTOR. 

-  THIS  FORMULA  WILL  BE  COMPLETED  BY  ADDING  THE  RADAR  SCAN; 
-TIME  DURING  SYSTEM  INITIALIZATION;  ! 


SMOOTH-ALTITUDE  (PROCESS  2.  2.  3.  3.  3): 

IF  RADAR-REPORT  CONTAINS  REPORT-ALTITUDE  THEN: 

CASE  1 

ALTITUDE-GATE  IS  AT  MAXIMUM; 

SMOOTHED-ALTITUDE  -  REPORT-ALTITUDE. 

CASE  2: 

ALTITUDE-GATE  IS  UNDER  MAXIMUM; 

SMOOTHED-ALTITUDE  *  (REPORT-ALTITUDE  +  OLD-ALTITUDE )  / 
2. 

END  CASE. 

ELSE- 

SMOOTHED-ALTITUDE  ■  OLD-ALTITUDE. 

END  IF! 


DET  . SMOOTHING-INDEX  (PROCESS  2.  2.  3.  3.  4): 

-  INDICES  TO  ACCESS  THE  SMOOTHING  CONSTANTS  RANGE  FROM; 

-  1  TO  5-  AN  INDEX  OF  1  REPRESENTS  A  NON  MANEUVERING 
TRACK; 

-  AND  SHALL  HAVE  THE  HEAVIEST  SMOOTHING  PERFORMED; 

CASE  1: 

TRACK  IS  NONMANEUVERING; 

-  INDEX  IS  i; 

IF  OUTERGATE  HAS  TWO  CONSECUTIVE  HITS  THEN: 

INDEX  *  5; 

RESET  TO  0 
ELSE: 

INDEX  =  1.  . 

CASE  2. 

TRACK  IS  MANEUVERING; 

-  INDEX  IS  2,  3,  4,  5; 

IF  TRACK  CORRELATED  IN  R-GATE ; 

INDEX  =  INDEX  -1. 

END  IF; 

IF  TRACK  CORRLATED  IS  OUTERGATE: 

INDEX  =  INDEX  +  1. 

END  IF' 
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PREDICTION.  < PROCESS  2.2.  3.  4); 

FOR  EACH  TRACK  LOOP: 

FROM  TRACK .STORAGE .FILE  GET: 
SMOOTHED.POSITIONi 
SMOOTHED. VELOCITY; 

CALCULATE  TIME .FROM.L AST. SMOOTHING; 
PREDICTED-POSITION  *  SMOOTHED.POSITION  +  ( 
TIME -FROM .LAST -SMOOTHING  +  SCAN-TIME) 
SMOOTHED-VELOCITY; 

UPDATE  TRACK.STORAGE-FILE ! 


EOI  ENCOUNTERED. 


1 


CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  =  DFD 


PA 


AC  K  _  (FLOW): 

^  MAKES  REFERENCES  TO 

AFFIRM_ACK  .  (ELEMENT) 

NEG_ACK  .  ( UNDEF ) 

IS  REFERENCED  BY 

TC-CC-MSG  .  (FLOW) 


ADD-  (FLOW): 

MAKES  REFERENCES  TO  " 
TRACK-REC  .  (FLOW) 

IS  REFERENCED  BY 

UPDATED-TRACK-REC  .  (FLOW) 


AFFIRM-ACK  (ELEMENT): 

"  MAKES  REFERENCES  TO  " 

IS  REFERENCED  BY 

ACK_ . (FLOW) 


ALGORITHM-INDICATOR  (UNDEF): 

MAKES  REFERENCES  TO 

IS  REFERENCED  BY 

INITIALIZATION-MSG  .  (FLOW) 


ALGORITHM-LIBRARY  (UNDEF); 

^  MAKES  REFERENCES  TO  ~~ 

—  IS  REFERENCED  BY  «- 
TARGET_CONTROL_DATA_BASE  .  .  .  (FILE) 


ALTITUDE.  (ELEMENT): 


MAKES  REFERENCES  TO 


IS  REFERENCED  BY 

LOCAL_RADAR_BUFF  .  (FLOW) 

1  CROSS  REFERENCE  REPORT  FOR  DD  ,,TCDD,‘  for  REF  *  DFD  PA 

GE  2 


OLD-ALTITUDE  .  (FLOW) 

REMOTE_RADAR_BUFF  .  (FLOW) 

REPORT-ALTITUDE  .  (FLOW) 

SMOOTHED-ALTITUDE  .  (FLOW) 

TRACK-ALTITUDE  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


ALTITUDE-GATE  (FLOW): 

^  MAKES  REFERENCES  TO 

IS  REFERENCED  BY 

SMOOTH-ALTITUDE . (PROCESS  2.  2.  3.  3.  3) 


ASSOCIATION-COUNT  (ELEMENT): 

MAKES  REFERENCES  TO 


IS  REFERENCED  BY  ~~ 
TRACK-DATA  .  (FLOW) 


ASSOC-DATA  (FLOW): 


•*-»  MAKES  REFERENCES  TO  " 


CONSECUTIVE-HIT  .  (ELEMENT) 

CONSECUTIVE-MISS  .  (ELEMENT) 

TRACK-NO  .  (ELEMENT) 


"  IS  REFERENCED  BY 
TGT-REP-BUFF  . 


(FLOW) 


AZIMUTH-  (ELEMENT): 


MAKES  REFERENCES  TO  " 
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IS  REFERENCED  BY 


LOCAI RADAR_BUFF . (FLOW) 

REMOTE _RADAR _BUFF  .  (FLOW) 


BEACON-INTERROGATION  ( UNDEF ) : 

MAKES  REFERENCES  TO 


IS  REFERENCED  BY 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  =  DFD 

GE  3 


MODE. 


(FLOW) 


CC-TC-MSG  (FLOW): 


MAKES  REFERENCES  TO 

ECM-REPORT  .  (FLOW) 

INITIAL I2ATI0N.MSG  .  (FLOW) 

MODE- . (FLOW) 

SWITCH_ACTION_DATA  .  (FLOW) 

TACTICAL-REPORT  .  (FLOW) 

TARGET-REPORT  .  .  (FLOW) 

IS  REFERENCED  BY 


CHAFF-DATA  (UNDEF). 


MAKES  REFERENCES  TO 


IS  REFERENCED  BY  — 

ECM-DAT  A . (FLOW) 


CLUTTER_MAP_FILE  (UNDEF): 

•V'  MAKES  REFERENCES  TO  ^ 

IS  REFERENCED  BY 

TARGET_CONTROL_DATA_BASE  .  .  .  (FILE) 


COMMAND-MSG  (UNDEF): 
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IW 


MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY-  " 

REMOTE -COMM- MSG  .  (FLOW) 


CONSECUTIVE-HIT  (ELEMENT): 

MAKES  REFERENCES  TO 

--  IS  REFERENCED  BY  -- 
ASSOC-DATA . .  .  (FLOW) 

1  CROSS  REFERENCE  REPORT  FOR  DD  11 TCDD"  for  REF  =  DFD  PA 

GE  4 

CONSECUTIVE-MISS  (ELEMENT): 

MAKES  REFERENCES  TO 

-v-  IS  REFERENCED  BY 
ASSOC-DATA  .  (FLOW) 


CONSECUTIVE-OUTERGATE-COUNT  (ELEMENT)  : 

MAKES  REFERENCES  TO 

IS  REFERENCED  BY  — 
CORRELATION-COUNT  .  (FLOW) 


CORRELATION-COUNT  (FLOW): 

■v-v  MAKES  REFERENCES  TO 


CONSECUTIVE-OUTERGATE-COUNT  .  .  (ELEMENT) 

INNERGATE-COUNT  .  (ELEMENT) 

OUTERGATE-COUNT  .  (ELEMENT) 

R-GATE-CNT  .  (ELEMENT) 


—  IS  REFERENCED  BY 
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AD-A123  308 
UNCLASSIFIED 


LARGE  SCALE  SOFTWARE  SVSTEM  DESIGN  OF  THE  MISSILE  '  6/6 

MINDER  AN/TSO-73  USING  T.  .  OJ>  CONTROL  DATA  CORP 
SHREWSBURV  NJ  GOVERNMENT  SVSTEMS  09  NOV  82 
DAAK80-81-C-8107  F7G  972  NL 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS-1963-A 


CURRENT. ASSOCIATED-REPORT-FILE  ( FLOW  > : 


"  MAKES  REFERENCES  TO  ■'«* 
REPORT-TO-TRACK-PAIR  .  (FLOW) 

**  IS  REFERENCED  BY 


CURRENT-TIME  (FLOW): 


"  MAKES  REFERENCES  TO  " 

TIME- . (ELEMENT) 

CROSS  REFERENCE  REPORT  FOR  OD  “TCDDM  for  REF  -  DFD  PA  w 

5  »  ’ 


'•v  IS  REFERENCED  BY 


_  . 

DEFENDED-POINT-FILE  ( UNDEF ) : 

-v'  MAKES  REFERENCES  TO 


IS  REFERENCED  BY  " 

TARCET-CONTROL-DATA-BASE  .  .  .  (FILE) 


-  -  LJj 

DELETE-  (FLOW): 

**  MAKES  REFERENCES  TO 
TRACK-REC  .  (FLOW) 

"  IS  REFERENCED  BY  ^  L- 

DROP-DATA  .  (FLOW) 

UPDATEO-TRACK-REC  .  (FLOW) 


DET-SMOOTHINC-INDEX  ( PROCESS  2.  2.  3.  3.  4  ) :  p_20 


R-GATE 


MAKES  REFERENCES  TO 


(ELEMENT) 


1 

GE  6 


**  IS  REFERENCED  BY  " 

SMOOTHING. . (PROCESS  2.  2.  3.  3) 


DEVIATION-VECTOR  (FLOW): 

***  MAKES  REFERENCES  TO  ^ 

VECTOR-  .  (FLOW) 

IS  REFERENCED  BY  ^ 

SMOOTH-POSTIION . (PROCESS  2.  2.  3.  3.1) 

SMOOTH-VELOCITY . (PROCESS  2.  2.  3.3.  2 > 

TRACK-DATA  .  (FLOW) 


DISPLAY-MSG  (FLOW): 

MAKES  REFERENCES  TO  " 

HOLD-FIRE-MSG  .  ( UNDEF ) 

OPERATOR-ALERT  . .  (FLOW) 

THREAT-PRIORITY  .  (ELEMENT) 

IS  REFERENCED  BY  " 

TC-CC-MSG  .  (FLOW) 

CROSS  REFERENCE  REPORT  FOR  DD  "TCDDM  for  REF  » 


ECM-REPORT  (FLOW): 


MAKES  REFERENCES  TO 

ECM-DATA  .  (FLOW) 

TRACK-NO  .  (ELEMENT) 


IS  REFERENCED  BY  ** 


CC-TC-MSG  .  (FLOW) 

TARGET-MSG  .  (FLOW) 


ENGAGEMENT-ALERT  ( UNDEF ) : 

MAKES  REFERENCES  TO  ** 

"  IS  REFERENCED  BY  " 
OPERATOR-ALERT  .  (FLOW) 


FU-STATUS-FILE  (UNDEF): 

MAKES  REFERENCES  TO 

IS  REFERENCED  BY 

TARGET-CONTROL-DATA-BASE  .  .  .  (FILE) 


CROSS  REFERENCE  REPORT  FOR  OD  "TCDD"  for  REF  ■  DFD 
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HOLD-FIRE-MSG  (UNDEF): 

**  MAKES  REFERENCES  TO 

^  IS  REFERENCED  BY 

DISPLAY-MSG  .  (FLOW) 


IFF-ALERT  (ELEMENT): 

"  MAKES  REFERENCES,  TO 

IS  REFERENCED  BY 

OPERATOR-ALERT  .  (FLOW)  l 


IFF-DATA  (FLOW): 


MAKES  REFERENCES  TO 


IN V ALIO -CODE  .  (ELEMENT) 

VALID-CODE  .  (ELEMENT) 

—  IS  REFERENCED  BY  " 

IFF-RECORD  .  (FLOW) 

LOCAL-RADAR-BUFF  .  (FLOW) 

REMOTE-COMM-REPORT  .  (FLOW) 

REMOTE-RADAR-BUFF  .  (FLOW) 

REMOTE-TRACK.PATA  .  (FLOW) 


IFF_RECORD  (FLOW): 

***  MAKES  REFERENCES  TO  -w* 
IFF-DATA  .  .  (FLOW) 

~~  IS  REFERENCED  BY  «•* 


INDEX-  (ELEMENT): 

•v-v  MAKES  REFERENCES  TO 

I 


IS  REFERENCED  BY  — 
OLD-INDEX  .  (FLOW) 


INITIALIZATION-DATA  ( FLOW ) : 

^  MAKES  REFERENCES  TO  " 

CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  -  DFD  PA 

B 

TARCET-CONTROI _ ALt  "‘RITHM  .  .  .  (UNDEF) 

TARCET-CONTROL-PARAMETER  .  .  .  (UNDEF) 

•v*  IS  REFERENCED  BY 
INITIALIZATION-MSC  .  (FLOW) 


INITIALIZATION-MSC  ( FLOW ) : 


MAKES  REFERENCES  TO 
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i 


ALGORITHM-INDICATOR  .  (UNDEF ) 

INITIALIZATION-DATA  .  (FLOW) 

«  IS  REFERENCED  BY 

CC-TC-MSG  .  (FLOW) 

TARGET-MSG  .  (FLOW) 


INITIAI _ TRACK -RECORD  (FLOW): 

"  MAKES  REFERENCES  TO  <** 


IS  REFERENCED  BY  -w* 


INNERGATE-COUNT  (ELEMENT): 

—  MAKES  REFERENCES  TO 


—  IS  REFERENCED  BY 


CORRELATION-COUNT  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


INVALID-CODE  (ELEMENT): 

MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  -w* 

IFF-DATA  . 

RESULT.  . 


(FLOW) 

(FLOW) 


JAM_STROBE_DATA  ( UNDEF ) : 

"  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  " 

CROSS  REFERENCE  REPORT  FOR  DD  HTCDDH  for  REF 
9 


DFD 


P 


ECM-DATA 


(FLOW) 


JAM_8TR0BE_FILE  (UNDEF): 
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LOCAL-RADAR-BUFF  ( FLOW ) : 


—  MAKES  REFERENCES  TO 

ALTITUDE-  . 

AZIMUTH-  . 

IFF-DATA  . 

RANGE-  . 

REPORT-NO  . 

SECTOR-NO  . 

TRACK-REC  . 


(ELEMENT) 

(ELEMENT) 

(FLOW) 

( UNDEF ) 
(ELEMENT) 
(ELEMENT) 
(FLOW) 


**  IS  REFERENCED  BY 
TARGET-REPORT  .  (FLOW) 


MERCE-ALERT  (UNDEF): 

•w*  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  " 
OPERATOR-ALERT  .  (FLOW) 


MODE.  (FLOW): 


**»<*•  MAKES  REFERENCES  TO  " 


BEACON-INTERROGATION  .  (UNDEF) 

TRACKING-MODE  .  (UNDEF) 

TRACK-INITIATION  .  (UNDEF) 

**  IS  REFERENCED  BY  " 

CC-TC-MSG  .  (FLOW) 

SYS-MODE  .  (FLOW) 

TARGET.MSG  .  (FLOW) 


NEGATIVE.ACK  (ELEMENT): 

•w*  MAKES  REFERENCES  TO  **•'« 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  -  DFD 

CE  10 
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IS  REFERENCED  BY  * 


NEG-ACK  (UNDEF): 

"  MAKES  REFERENCES  TO  ** 


IS  REFERENCED  BY 

ACK_ . (FLOW) 


NON- ASSOC _TGT_REP  (FLOW): 

MAKES  REFERENCES  TO 


TARGET-REPORT  .  (FLOW) 

IS  REFERENCED  BY 

NON-MATCHING-TGT-REP  .  (FLOW) 


NON-ASSOC-TRACK  (FLOW): 

MAKES  REFERENCES  TO  *w<w 


TRACK-NO  .  (ELEMENT) 

"  IS  REFERENCED  BY  — 
NON-MATCHING -TRACK  .  (FLOW) 


NON-CORREL-TGT-REP  (FLOW): 

*"*>  MAKES  REFERENCES  TO  ^ 


TARGET-REPORT  .  (FLOW) 

IS  REFERENCED  BY 

NON_MATCHING-TGT_REP  .  (FLOW) 


NON-CORREL-TRACK  (FLOW): 

MAKES  REFERENCES  TO  ** 


TRACK-NO  .  (ELEMENT) 

IS  REFERENCED  BY  *"'< 

NON-MATCHING_TRACK  .  (FLOW) 


V 


NON-MATCHING-TGT-REP  (FLOW): 

1  CROSS  REFERENCE  REPORT  FOR  DD  “TCDD*  for  REF  ■  DFD  PA 

GE  11 


*«v  MAKES  REFERENCES  TO 


NON_ASSOC_TGT_REP  .  (FLOW) 

NON-CORREL-TGT-REP  .  (FLOW) 

**  IS  REFERENCED  BY  *•*« 
TGT_REP_BUFF  .  (FLOW) 


NON_MATCHING_TRACK  (FLOW): 

MAKES  REFERENCES  TO  ^ 

NON_ ASSOC -TRACK  .  (FLOW) 

NON-CORREL-TRACK  .  (FLOW) 

<**<.  IS  REFERENCED  BY 


NORTH-SECTOR-PULSE  (UNDEF): 

«  MAKES  REFERENCES  TO 


-v*  IS  REFERENCED  BY 
TARGET-MSG  .  (FLOW) 


OLD-ALTITUDE  (FLOW): 

MAKES  REFERENCES  TO  — 

ALTITUDE-  .  (ELEMENT) 

IS  REFERENCED  BY 

SMOOTH-ALTITUDE . .  .  (PROCESS  2.  2.  3.  3.  3) 


OLO-INDEX  (FLOW): 

^  MAKES  REFERENCES  TO 
INDEX-  . 

IS  REFERENCED  BY  “■ 


(ELEMENT) 


F-27 


OLD-POSITION  (FLOW): 


**  MAKES  REFERENCES  TO  ‘v* 

POSITION-  .  (FLOW) 

—  IS  REFERENCED  BY  — 

SMOOTH.POSTIION . (PROCESS  2.  2.  3.  3.  1) 

1  CROSS  REFERENCE  REPORT  FOR  DD  “TCDDH  for  REF  =  DFD  PA 

CE  12 


OLD-VELOCITY  (FLOW): 

***  MAKES  REFERENCES  TO 
VELOCITY-  .  (ELEMENT) 


"  IS  REFERENCED  BY 
SMOOTH. VELOCITY  . 


(PROCESS  2.  2.  3.  3.  2) 


OPERATOR .ALERT  ( FLOW ) : 

•w  MAKES  REFERENCES  TO  — 


ENGAGEMENT-ALERT  .  (UNDEF) 

IFF-ALERT  .  (ELEMENT) 

MERGE-ALERT  .  (UNDEF) 


—  IS  REFERENCED  BY 
DISPLAY.MSG  . 


(FLOW) 


OPERATOR-REQUESTS  ( UNDEF ) : 

MAKES  REFERENCES  TO  ^ 

"  IS  REFERENCED  BY  — 
SWITCH.ACTION.OATA  .  (FLOW) 


OUTERGATE.COUNT  (ELEMENT): 

•v'  MAKES  REFERENCES  TO 


IS  REFERENCED  BY  ■'"* 


CORRELATION-COUNT  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


F-28 


POOR -TRAC KING -STATUS -INDICATOR  (FLOW): 


"  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY 


POSITION.  (FLOW): 


^  MAKES  REFERENCES  TO  -v* 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  *  DFD  PA 

GE  13 


VECTOR- 


(FLOW) 


"  IS  REFERENCED  BY 


OLD-POSITION  .  (FLOW) 

PREDICTED-POSITION  .  (FLOW) 

SMOOTHED -POSITION  .  (FLOW) 


PREDICTED -POSITION  (FLOW): 

MAKES  REFERENCES  TO  <*•* 
POSITION-  .  (FLOW) 


**  IS  REFERENCED  BY  " 

PREDICTION- . (PROCESS  2.  2.  3.  4) 

TRACK-DATA  .  .  (FLOW) 


PREDICTED-VELOCITY  (FLOW): 

MAKES  REFERENCES  TO  " 
VELOCITY-  .  (ELEMENT) 

IS  REFERENCED  BY  ^ 

TRACK-DATA  .  (FLOW) 


PREDICTION-  (PROCESS  2.  2.  3.  4): 

MAKES  REFERENCES  TO 

PREDICTED-POSITION  .  (FLOW) 

SCAN-TIME  .  (FLOW) 

SMOOTHEO-POSITION  .  (FLOW) 

SMOOTHED-VELOCITY  .  (FLOW)  p-29 


TIME-FROM-LAST-SMOOTHING  .  .  .  (FLOW) 

TRACK -STORAGE -FILE  .  (FILE) 


—  IS  REFERENCED  BY 


PRIMARY-ASSIGN  ( UNDEF ) : 

MAKES  REFERENCES  TO  <«•* 

IS  REFERENCED  BY 

REMOTE-COMM-MSG  .  (FLOW) 


RADAR-REPORT  (FLOW): 

**  MAKES  REFERENCES  TO  " 

CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  =  DFD  PA 

14 


TARGET-REPORT  .  .  (FLOW) 

-v*  IS  REFERENCED  BY 

RADAR-REPORT-BUFFER  .  (FLOW) 

SMOOTH-ALTITUDE . (PROCESS  2.  2.  3.  3.  3) 


RADAR-REPORT-BUFFER  (FLOW): 

*■'-  MAKES  REFERENCES  TO  " 
RADAR-REPORT  .  (FLOW) 


IS  REFERENCED  BY 


RANGE-  (UNDEF): 


"  MAKES  REFERENCES  TO  " 


IS  REFERENCED  BY  ^ 


LOCAL_RADAR_BUFF  .  (FLOW) 

REMOTE-RADAR-BUFF  .  (FLOW) 


REMOTE-COMM-MSG  (FLOW): 


F-30 


—  MAKES  REFERENCES  TO 


COMMAND-MSG . <  UNDEF ) 

PRIMARY- ASSIGN  .  (UNDEF) 

SECONDARY-ASSIGN  .  (UNDEF) 


IS  REFERENCED  BY 


REMOTE-COMM-REPORT  (FLOW): 

"  MAKES  REFERENCES  TO 

IFF-DATA  .  (FLOW) 

TRACK-NO  .  (ELEMENT) 


IS  REFERENCED  BY 

TARGET-REPORT  .  (FLOW) 


REMOTE_RADAR_BUFF  (FLOW): 


MAKES  REFERENCES  TO 


1 

GE  15 

ALTITUDE-  . 

AZIMUTH-  . 

IFF-DATA  . 

CROSS  REFERENCE  REPORT  FOR  DD  MTCDDM 

(ELEMENT) 

(ELEMENT) 

(FLOW) 

for  REF  *  DFD 

PA 

RANGE-  . 

REPORT-NO  . 

SECTOR-NO  . 

TRACK-REC  . 

(UNDEF) 

(ELEMENT) 

(ELEMENT) 

(FLOW) 

IS  REFERENCED  BY 
TARGET-REPORT  . 

(FLOW) 

REMOTE-TRACK-DATA  (FLOW): 

MAKES  REFERENCES  TO  ■'"* 

IFF-DATA  .  (FLOW) 

TRACK-NO  .  (ELEMENT) 


IS  REFERENCED  BY 


REPORT-ALTITUDE  (FLOW): 

MAKES  REFERENCES  TO  " 

ALTITUDE-  .  (ELEMENT) 

F-31 


IS  REFERENCED  BY 

SMOOTHING- . (PROCESS  2.  2.  3.  3) 

SMOOTH-ALTITUDE . (PROCESS  2.  2.  3.  3.  3) 


REPORT-NO  (ELEMENT): 

—  MAKES  REFERENCES  TO  " 


"  IS  REFERENCED  BY 


LOCAL-RADAR-BUFF  .  (FLOW) 

REMOTE_RADAR_BUFF  .  (FLOW) 

REPORT-TO-TRACK-PAIR  .  (FLOW) 


REPORT-TO-TRACK-PAIR  (FLOW): 


"  MAKES  REFERENCES  TO  ** 

REPORT-NO  .  (ELEMENT) 

TRACK-NO  .  (ELEMENT) 


"  is  REFERENCED  BY 
CURRENT-ASSOCIATED-REPORT -FILE  (FLOW) 

SMOOTHING- . (PROCESS  2.  2.  3.  3) 

TGT-REP-BUFF  .  (FLOW) 


RESULT.  (FLOW). 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  ■  DFD  PA 

CE  16 


^  MAKES  REFERENCES  TO 

INVALID-CODE  .  (ELEMENT) 

VALID-CODE  .  (ELEMENT) 


is  REFERENCED  BY 


R-GATE  (ELEMENT): 

"  MAKES  REFERENCES  TO 


IS  REFERENCED  BY 

DET-SMOOTHING-INDEX . (PROCESS  2.  2.  3.  3.  4) 


F-32 


R-GATE-CNT  (ELEMENT): 


MAKES  REFERENCES  TO  ** 


IS  REFERENCED  BY 

CORRELATION- COUNT  .  (FLOW) 


SAFE_CORRIDOR_FILE  ( UNDEF ) : 

-v'  MAKES  REFERENCES  TO  " 

"  IS  REFERENCED  BY  *<* 
TARGET_CONTROL_DATA_BASE  .  .  .  (FILE) 


SC AN-TIME  (FLOW): 

MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  •»<'• 

PREDICTION- . (PROCESS  2.  2.  3.  4) 

SMOOTH-VELOCITY . (PROCESS  2.  2.  3.  3.  2) 

SYSTEM-PARAMETER-FILE  .  (FILE) 


SECONDARY-ASSIGN  (UNOEF) : 

MAKES  REFERENCES  TO 


*"'■  IS  REFERENCED  BY 

CROSS  REFERENCE  REPORT  FOR  DD  “TCDD"  for  REF  =  DFD 
17 


PA 


REMOTE-COMM-MSG 


(FLOW) 


SECTOR-NO  (ELEMENT): 

•'"*  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY 


LOCAL-RADAR-BUFF  .  (FLOW) 

REMOTE-RADAR-BUFF  .  (FLOW) 


SECTOR-PULSE  <  UNDEF  ) : 


MAKES  REFERENCES  TO 

"  IS  REFERENCED  BY  -w' 
TARCET-MSG  .  (FLOW) 


SLACK-TIME  (UNDEF): 

"  MAKES  REFERENCES  TO  " 

"  IS  REFERENCED  BY  " 
TACTICAL-DATA  .  (FLOW) 


SMOOTHED-ALTITUDE  (FLOW): 

"  MAKES  REFERENCES  TO 
ALTITUDE-  .  (ELEMENT) 


—  IS  REFERENCED  BY 

SMOOTHED-DATA  .  (FLOW) 

SMOOTH-ALTITUDE . (PROCESS  2.  2.  3.  3.  3) 

TRACK-DATA  .  (FLOW) 


SMOOTHED-DATA  ( FLOW ) : 

**  MAKES  REFERENCES  TO 


SMOOTHED-ALTITUDE  .  (FLOW) 

SMOOTHED-POSITION  .  (FLOW) 

SMOOTHED-VELOCITY  .  (FLOW) 

SMOOTHING-INDEX  .  (ELEMENT) 

TIME-OF-LAST-SMOOTHING  ....  (FLOW) 


"  IS  REFERENCED  BY  -v* 

CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  *  DFD 
IB 


SMOOTHED-POSITION  (FLOW): 

•v*  MAKES  REFERENCES  TO  *'* 
POSITION-  .  (FLOW) 

"  IS  REFERENCED  BY  <*-*<•  F_34 


PREDICTION.  . 

SMOOTHED-DATA 

TRACK-DATA 


(PROCESS  2.  2.  3.  4) 
(FLOW) 

(FLOW) 


SMOOTHED. VELOCITY  (FLOW): 

MAKES  REFERENCES  TO  <** 
VELOCITY.  .  (ELEMENT) 


**  IS  REFERENCED  BY  " 

PREDICTION. . (PROCESS  2.  2.  3.  4) 

SMOOTHED-DATA  .  (FLOW) 

SMOOTH-VELOCITY . (PROCESS  2.  2.  3.  3.  2) 

TRACK.OATA  .  (FLOW) 


SMOOTHING.  (PROCESS  2.  2.  3.  3): 

"  MAKES  REFERENCES  TO  " 

DET-SMOOTHINC.INDEX . (PROCESS  2.  2.  3.  3.  4) 

REPORT-ALTITUDE  .  (FLOW) 

REPORT. TO-TRACK.PAIR  .  (FLOW) 

SMOOTH-ALTITUDE . (PROCESS  2.  2.  3.  3.  3) 

SMOOTH-POSITION  .  (UNDEF) 

SMOOTH-VELOCITY . (PROCESS  2.  2.  3.  3.  2) 

TRACK-STORAGE-FILE  .  (FILE) 

"  IS  REFERENCED  BY 


SMOOTHING-CONSTANTS  ( FLOW ) : 

"  MAKES  REFERENCES  TO 
SMOOTH-POSITION-CONSTANT  .  .  .  (ELEMENT) 

SMOOTH-VELOCITY-CONSTANT  .  .  .  (ELEMENT) 

"  IS  REFERENCED  BY  " 

SMOOTHING-CONSTANT-TABLE  .  .  .  (FILE) 

SYSTEM-PARAMETER-FILE  .  (FILE) 


SMOOTHING-CONSTANT-TABLE  (FILE): 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  «  DFD  PA 
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"  MAKES  REFERENCES  TO  ^ 
SMOOTHING-CONSTANTS  .  (FLOW) 


**  IS  REFERENCED  BY 


F-35 


SMOOTH -POSITION . (PROCESS  2.  2.  3.  3.1) 

TARGET -CONTROI _ DAT  A-BASE  .  .  .  (FILE) 


SMOOTHING-INDEX  (ELEMENT): 

"  MAKES  REFERENCES  TO 

"  IS  REFERENCED  BY 


SMOOTHED-DATA  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


SMOOTH-ALTITUDE  (PROCESS  2.  2.  3.  3.  3): 

""v  MAKES  REFERENCES  TO  " 


ALTITUDE-GATE  .  (FLOW) 

OLD-ALTITUDE  .  (FLOW) 

RADAR-REPORT  .  (FLOW) 

REPORT-ALTITUDE  .  (FLOW) 

SMOOTHED-ALTITUDE  .  (FLOW) 


IS  REFERENCED  BY  ** 
SMOOTHING-  . 


(PROCESS  2.  2.  3.  3) 


eae 


SMOOTH-POSITION  ( UNDEF ) : 

**  MAKES  REFERENCES  TO  " 


*-» 


**  IS  REFERENCED  BY  " 

SMOOTHING- . (PROCESS  2.  2.  3.  3) 

SMOOTH-POSTIION . (PROCESS  2.  2.  3.  3.1) 


SMOOTH-POSITION-CONSTANT  ( ELEMENT  ) : 


U 


^  MAKES  REFERENCES  TO  -w* 


IS  REFERENCED  BY  — 

SMOOTHING-CONSTANTS  .  (FLOW) 

SMOOTH-POSTIION . (PROCESS  2.  2.  3.  3.1) 


SMOOTH-POSTIION  (PROCESS  2.  2.  3.  3.1): 


1 


CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  ■  DFD  f-36 


PA 


CE  20 


*'«'<  MAKES  REFERENCES  TO  -w* 


DEVIATION-VECTOR  .  (FLOW) 

OLD-POSITION  .  (FLOW) 

SMOOTHING-CONSTANT-TABLE  .  .  .  (FILE) 

SMOOTH-POSITION  .  ( UNDEF ) 

SMOOTH-POSITION-CONSTANT  .  .  .  (ELEMENT) 


F.*-' 


IS  REFERENCED  BY  — 


SMOOTH-VELOCITY  (PROCESS  2.  2.  3.  3.  2): 

**  MAKES  REFERENCES  TO 

DEVIATION-VECTOR  .  (FLOW) 

OLD-VELOCITY  .  (FLOW) 

SCAN-TIME  .  (FLOW) 

SMOOTHED-VELOCITY  .  (FLOW) 

SMOOTH-VELOCITY-CONSTANT  .  .  (ELEMENT) 

"  IS  REFERENCED  BY  — 

SMOOTHING. . (PROCESS  2.  2.  3.  3) 


SMOOTH-VELOCITY-CONSTANT  (ELEMENT): 

‘  *  * 

-w*  MAKES  REFERENCES  TO  ** 

"  IS  REFERENCED  BY  *•'. 

I  SMOOTHING-CONSTANTS  .  (FLOW) 

\y  SMOOTH-VELOCITY . .  (PROCESS  2.  2.  3.  3.  2) 


STATUS-  (FLOW): 


MAKES  REFERENCES  TO  " 

"  IS  REFERENCED  BY  " 
TRACK-DATA  .  (FLOW) 


SWITCH-ACTION-DATA  (FLOW): 


MAKES  REFERENCES  TO 


ECM-DATA  .  (FLOW) 

OPERATOR-REOUESTS  .  (UNDEF) 

TACTICAL-DATA  .  (FLOW) 

TRACK-OATA  .  (FLOW) 


"  IS  REFERENCED  BY 


CC-TC-MSG  .  (FLOW) 

TARGET-CONTROL-DATA  .  (FLOW) 


CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  «  DFD  PA 
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SYSTEM-PARAMETER-FILE  (FILE): 

*'*•*  MAKES  REFERENCES  TO 


SCAN-TIME  .  (FLOW) 

SMOOTHING-CONSTANTS  .  (FLOW) 

SYS-MODE  .  (FLOW) 


IS  REFERENCED  BY  ** 
TARGET-CONTROL-DATA-BASE  .  .  .  (FILE) 


SYS-MODE  (FLOW): 

**  MAKES  REFERENCES  TO 


MODE- . (FLOW) 

**  IS  REFERENCED  BY 
SYSTEM-PARAMETER-FILE  .  (FILE) 


TACTICAL-DATA  (FLOW): 

MAKES  REFERENCES  TO  •**'- 


SLACK-TIME  .  (UNDEF) 

THREAT-PRIORITY  .  (ELEMENT) 

TRACK-NO  .  (ELEMENT) 


"  IS  REFERENCED  BY  ^ 


SWITCH-ACTION-DATA  .  (FLOW) 

TARGET-CONTROL-DATA  .  (FLOW) 


TACTICAL-REPORT  (FLOW): 

“"v  MAKES  REFERENCES  TO 


TAC-RPT-BODY  .  (UNDEF) 

TAC-RPT-HEADER  .  (UNDEF) 

IS  REFERENCED  BY  ^ 

CC-TC-MSG  .  (FLOW) 

TARGET-MSG  .  (FLOW) 


TAC-RPT-BODY  ( UNOEF ) : 


MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY 
TACTICAL-REPORT  .  (FLOW) 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  ■  DFD  PA 
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TAC-RPT-HEADER  ( UNOEF ) : 

MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  ** 
TACTICAL-REPORT  .  (FLOW) 


TARGET -CONTROL-ALGORITHM  (UNOEF) : 

"  MAKES  REFERENCES  TO  ** 


■v'  IS  REFERENCED  BY 
INITIALIZATION-DATA  .  (FLOW) 


TARGET-CONTROL-DATA  (FLOW): 

**  MAKES  REFERENCES  TO 


ECM-DATA  .  (FLOW) 

SWITCH-ACTION-DATA  .  (FLOW) 

TACTICAL-DATA  .  (FLOW) 

TRACK-DATA  .  (FLOW) 

IS  REFERENCED  BY  *•'- 
TC-CC-MSG  .  (FLOW) 


TARGET-CONTROL-DATA-BASE  (FILE): 

MAKES  REFERENCES  TO 

ALGORITHM-LIBRARY  .  ( UNDEF ) 

CLUTTER-MAP-FILE  .  (UNDEF) 

DEFENDED-POINT-FILE  .  (UNDEF) 

FU-STATUS-FILE  .  (UNDEF) 

JAM-STROBE-FILE  .  (UNDEF)  F_39 


SAFE -CORRIDOR -FILE  .  ( UNDEF ) 

SMOOTHING-CONSTANT-TABLE  .  .  .  (FILE) 

SYSTEM-PARAMETER-FILE  .  (FILE) 

THREAT-ALGORITHM-FILE  .  (UNDEF) 

THREAT-PARAMETER-FILE  .  (UNDEF) 

TRACK-ALGORITHM-FILE  .  (UNDEF) 

TRACK-PARAMETER-FILE  .  (UNDEF) 

TRACK-STORAGE-FILE  .  (FILE) 

WEAPON-ASGN  .  (UNDEF) 

WEAPON-ASSIGN-ALGORITHM-FILE  .  (UNDEF) 


"  IS  REFERENCED  BY  '>'• 


CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  ■  DFD 
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PA 


TARGET-CONTROL-PARAMETER  < UNDEF ) : 

^  MAKES  REFERENCES  TO 

IS  REFERENCED  BY  ** 

INITIALIZATION-DATA  .  (FLOW) 


TARGET-MSG  (FLOW): 

**  MAKES  REFERENCES  TO  " 


ECM-REPORT  .  (FLOW) 

INITIALIZATION-MSG  .  (FLOW) 

MODE- . (FLOW) 

NORTH-SECTOR-PULSE  .  (UNDEF) 

SECTOR-PULSE  .  (UNDEF) 

TACTICAL-REPORT  .  (FLOW) 

TARGET-REPORT  .  (FLOW) 


^  IS  REFERENCED  BY  " 


TARGET-REPORT  ( FLOW )  : 

MAKES  REFERENCES  TO  ^ 


LOCAL-RADAR-BUFF  .  (FLOW) 

REMOTE-COMM-REPORT  .  (FLOW) 

REMOTE-RADAR-BUFF  .  (FLOW) 

'*■  IS  REFERENCED  BY  -w* 

CC-TC-MSG  .  (FLOW) 

NON. ASSOC -TCT -REP  .  (FLOW) 

NON-CORREi _ TGT-REP . (FLOW) 

RADAR-REPORT  .  (FLOW) 


TARGET-MSG 


(FLOW) 


TC-CC-MSG  (FLOW): 


"  MAKES  REFERENCES  TO 


ACK_ . (FLOW) 

DISPLAY-MSG  .  (FLOW) 

TARGET-CONTROL-DATA  .  (FLOW) 

TC-REM-COMM-MSG  .  (UNDEF) 


IS  REFERENCED  BY 


,  TC_REM_COMM_MSG  (UNDEF): 
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GE  24 

MAKES  REFERENCES  TO  -v* 

"  TS  REFERENCED  BY 

TC--CC-MS,G . (FLOW) 


TGT-REP-BUFF  (FLOW): 

MAKES  REFERENCES  TO  " 


ASSOC-DATA  . '(FLOW) 

NON-MATCHING-TGT-REP  .....  (FLOW) 

REPORT-TO-TRACK-PAIR  ' . (FLOW), 

TRACK -QUALITY  .  V  (FLOW) 


IS  REFERENCED  BY  w  ^  ' 


j 

THREAT-ALGORITHM-FILE  (UNDEF): 

"  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY 
TARGET-CONTROL-DATA -BASE  .  .  .  (FILE) 


THREAT-PARAMETER-FILE  (UNDEF): 


F-4I 


**  MAKES  REFERENCES  TO 


IS  REFERENCED  BY 

TARGET -CONTROI _ DATA-BASE  .  .  .  (FILE) 


THREAT-PRIORITY  (ELEMENT): 

MAKES  REFERENCES  TO  '*>*' 

•'"*  IS  REFERENCED  BY 


DISPLAY-MSG  .  (FLOW) 

TACTICAL-DATA  .  (FLOW) 


TIME-  (ELEMENT): 

—  MAKES  REFERENCES  TO 


"  IS  REFERENCED  BY  *<* 

1  CROSS  REFERENCE  REPORT  FOR  OD  "TCDD”  for  REF  «  DFD 

GE  25 


PA 


f: 3 


CURRENT-TIME  .  (FLOW) 

TIME-FROM-LAST-SMOOTHING  .  .  .  (FLOW) 

TIME_OF_LAST_SMOOTHING  ....  (FLOW) 


TIME-FROM-LAST-SMOOTHING  ( FLOW ) : 

"  MAKES  REFERENCES  TO  " 

TIME- . (ELEMENT) 

"  IS  REFERENCED  BY  *■* 

PREDICTION- . (PROCESS  2.  2.  3.  4) 


TIME-OF-LAST-SMOOTHING  (FLOW): 

^  MAKES  REFERENCES  TO 
'TIME.  .  (ELEMENT) 


^  IS  REFERENCED  BY  ** 


SMOOTHED-DATA  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


F-42 


TRAC KING. MODE  ( UNDEF ) : 


**  MAKES  REFERENCES  TO  ** 


MODE. 


*<•*  IS  REFERENCED  BY  " 
.  (FLOW) 


TRACK. ALGORITHM-FILE  ( UNDEF ) : 

"  MAKES  REFERENCES  TO  " 

IS  REFERENCED  BY  " 

TARGET .CONTROI _ DATA .BASE  .  .  .  (FILE) 


TRACK-ALTITUDE  (FLOW): 

**  MAKES  REFERENCES  TO 
ALTITUDE.  .  (ELEMENT) 


"  IS  REFERENCED  BY  " 


TRACK. DATA  (FLOW): 
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MAKES  REFERENCES  TO 


ALTITUDE.  .  (ELEMENT) 

ASSOCIATION-COUNT  (ELEMENT) 

DEVIATION-VECTOR  .  (FLOW) 

INNERGATE-COUNT  .  (ELEMENT) 

OUTERGATE. COUNT  .  (ELEMENT) 

PREDICTED-POSITION  .  (FLOW) 

PREDICTED-VELOCITY  .  (FLOW) 

SMOOTHED-ALTITUDE  .  (FLOW) 

SMOOTHED-POSITION  .  (FLOW) 

SMOOTHED-VELOCITY  .  (FLOW) 

SMOOTHING-INDEX  .  (ELEMENT) 

STATUS-  .  (FLOW) 

TIME -OF. LAST- SMOOTHING  ....  (FLOW) 
TRACK-NO  .  (ELEMENT) 


IS  REFERENCED  BY  ** 


SWITCH- ACTION-DATA  .  (FLOW) 

TARGET-CONTROL-DATA  .  (FLOW) 

TRACK-REC  .  (FLOW) 

TRACK-STORAGE-FILE  .  (FILE) 


F-43 


TRACK -INITIATION  <  UNDEF ) : 


MAKES  REFERENCES  TO 


IS  REFERENCED  BY 

MODE-  .  . (FLOW) 


TRACK-NO  (ELEMENT) 

MAKES  REFERENCES  TO  " 


IS  REFERENCED  BY  -- 


ASSOC-OATA  .  (FLOW) 

ECM-REPORT  .  (FLOW) 

NON-ASSOC-TRACK  .  (FLOW) 

NON-CORREL-TRACK  .  (FLOW) 

REMOTE-COMM-REPORT  .  (FLOW) 

REMOTE-TRACK-DATA  .  (FLOW) 

REPORT-TO-TRACK-PAIR  .  (FLOW) 

TACTICAL-DATA  .  (FLOW) 

TRACK-DATA  .  (FLOW) 


>  * 


TRACK-PARAMETER-FILE  (UNDEF):  ££ j 

^  MAKES  REFERENCES  TO 

i  CROSS  REFERENCE  REPORT  FOR  DD  11 T C D D “  for  REF  *  DFD  PA 
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**  IS  REFERENCED  BY 
TARGET_CONTROL_DATA_BASE  .  .  .  (FILE) 


TRACK-QUALITY  (FLOW): 

•v*  MAKES  REFERENCES  TO 

^  IS  REFERENCED  BY  ^ 
TGT-REP-BUFF  .  (FLOW) 


TRACK-REC  (FLOW): 


F-44 


#V  A, 


MAKES  REFERENCES  TO 


*\#  *V 


TRACK-DATA 


(FLOW) 


"  IS  REFERENCED  BY 


ADD- . (FLOW) 

DELETE-  .  (FLOW) 

LOCAL-RADAR-BUFF  .  (FLOW) 

REMOTE -RADAR -BUFF  .  (FLOW) 


TRACK-STORAGE-FILE  (FILE); 

MAKES  REFERENCES  TO  -v* 
TRACK-DATA  .  (FLOW) 


"  IS  REFERENCED  BY 

PREDICTION- . (PROCESS  2.  2.  3.  4) 

SMOOTHING- . (PROCESS  2.  2.  3.  3) 

TARGET_CONTROL_DATA_BASE  .  .  .  (FILE) 


UPDATED-TRACK-REC  (FLOW): 

MAKES  REFERENCES  TO  •>"w 

ADD- . (FLOW) 

DELETE.  .  (FLOW) 


IS  REFERENCED  BY 

UPDATE-DATA  .  (FLOW) 


UPDATE-DATA  (FLOW): 

MAKES  REFERENCES  TO  ^ 

UPDATED-TRACK-REC  .  (FLOW) 

—  IS  REFERENCED  BY 

1  CROSS  REFERENCE  REPORT  FOR  DD  "TCDD"  for  REF  -  DFD  PA 
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VALID-CODE  (ELEMENT): 

"  MAKES  REFERENCES  TO 


IS  REFERENCED  BY 


IFF-DATA 

RESULT. 


(FLOW) 

(FLOW) 

F-45 


VECTOR-  (FLOW): 


"  MAKES  REFERENCES  TO 


X-COORD  .  (ELEMENT) 

Y-COORD  .  (ELEMENT) 

IS  REFERENCED  BY 

DEVIATION-VECTOR  .  (FLOW) 

POSITION-  .  (FLOW) 


VELOCITY.  (ELEMENT): 

MAKES  REFERENCES  TO 

--  IS  REFERENCED  BY 


OLD-VELOCITY  .  (FLOW) 

PREDICTED-VELOCITY  .  (FLOW) 

SMOOTHED-VELOCITY  .  (FLOW) 


WEAPON-ASGN  ( UNDEF ) ■ 

"  MAKES  REFERENCES  TO  " 


**  IS  REFERENCED  BY 
TARGET_CONTROL_DATA_BASE  .  .  . 


(FILE) 


fc  M. 


WEAPON-ASSIGN-ALGORITHM-FILE  ( UNDEF  > : 

**  MAKES  REFERENCES  TO 

"  IS  REFERENCED  BY  ^ 
TARGET-CONTROL_DATA_BASE  .  .  .  (FILE) 
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X-COORD  (ELEMENT): 


MAKES  REFERENCES  TO  ** 


IS  REFERENCED  BY 


•W  Ai 


F-46 


VECTOR- 


(FLOW) 


Y-COORD  (ELEMENT): 


"  MAKES  REFERENCES  TO 

IS  REFERENCED  BY  — 
VECTOR-  . 


«v«v 


(FLOW) 


EOI  ENCOUNTERED. 
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(ALSO  DELIVERED  UNDER  CDRL  AOOl) 

FINAL  REPORT 


LARGE  SCALE  SOFTWARE  SYSTEM  DESIGN 
FOR  THE 

MISSILE  MINDER  AN/TSQ-73 
USING 

THE  ADA  PROGRAMMING  LANGUAGE 


PREPARED  FOR 

U.S.  ARMY  COMMUNICATIONS  ELECTRONICS  COMMAND 
FORT  MONMOUTH,  NEW  JERSEY  07703 


The  SECTOR-PROCESSING-CONTROLLER  is  the  highest  level  prodram  unit  in  the 
implementation  of  the  structure  chart  entity  TRACKING*  It  contains  the 
control  Iodic  necessary  to  implement  the  scheme  of  havind  one  task  to 
process  each  sectors  worth  of  radar  reports* 

<><><><><><><><><>  INITIALIZATION  OOOOOOOOOOOOOOOOOOOOO 

The  SECTOR-PROCESSING-CONTROLLER  is  started  up  by  the  reception  of 
a  sidnal  from  the  radar  interface  eauiptment  (RIE)  indicating  that 
this  device  is  ready  for  normal  service*  The  SECTOR-PROCESSING- 
controller  then  waits  for  the  first  north  sector  pulse  to  be  trans¬ 
mitted  by  the  RIE*  The  reception  of  this  pulse  accomplishes  the 
initial  synchronization  of  the  SECTOR-PROCESSING-CONTROLLER  with  the 
radar  scan  interval* 

<><><><><><><><><>  NORMAL  OPERATION  <><><><><><><><><><><><><><><><><><><><> 

Upon  reception  of  the  pulse  immediately  followind  the  north  sector  pulse 
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—  the  SECTOR-PROCESSING-CONTROLLER  begins  noreel  operation.  Noreel  operation 

—  consists  of  a  seauence  of  three  activities  which  take  place  in  synchronizati 
n 

—  with  radar  scan  tiee*  The  three  activities  aret  1.  rendezvous  with  the  RIE 

—  to  obtain  the  radar  reports  for  the  sector  Just  scanned?  2.  notification  of 

—  the  task  processing  three  sectors  ‘ahead*  that  it  eust  begin  prediction?  and 

—  3*  initiation  of  processing  the  current  sector  by  the  appropriate  task* 

—  <><><><><><><><><><>  ERROR  SITUATIONS  <><><><><><><><><><><><><><><><><><><> 

Synchronization  with  the  RIE  eust  be  eaintained*  This  synchronization  is 

—  checked  after  the  reception  of  each  sectors  worth  of  radar  reports*  In  the 

—  event  of  loss  of  synchronization  the  SECTOR-PROCESSING-CONTROLLER  will  re- 

—  synch  itself  to  the  sector  that  the  RIE  passed*  Tasks  processing  the 

--  sectors  passed  over  by  this  re-synch  will  return  to  synch  on  the  next  scan 


task  SECTOR-PROCESSING-CONTROLLER  is 
entry  RIE-START-UP-DONE) 
entry  NORTH-SECTOR-PULSE? 

entry  NEW-SECTOR_PULSE<R  t  in  RADAR-REPORT-BUFFER) ) 
end  SECTOR-PROCESSING-CONTROLLER? 

task  body  SECTOR-PROCESSING-CONTROLLER  is 

PROCESSOR-LIST  :  array  (SECTOR 'FIRST ♦ .SECTOR' LAST)  of  TRACK-WHILE-SCAN? 

R  !  RADAR-REPORT-BUFFER) 

CURRENT-SECTOR  *  SECTOR  i*  1?  --  local  sector  counter 

begin 

accept  RIE-START-UP-DONE) 
accept  NORTH-SECTOR-PULSE) 

loop 

accept  NEW-SECTOR-PULSE ( R  l  in  RADAR-REPORT-BUFFER)) 

if  SECTOR-OF <R)  /=  CURRENT-SECTOR  then— reestabl ish  lost  synchronization 
do 

send  a  Message  to  the  CSC 
CURRENT-SECTOR  J*  SECTOR-OF < R ) ) 


end? 
end  if? 


—  terminate  task  processing  three  sectors  'ahead*  of  current  sector 
PROCESSOR-LIST ( CURRENT_SECTOR  +  2  aod  SECTOR 'LAST  +  1).ST0P* 

—  initiate  task  to  process  the  sector  data  Just  received 
PROCESSOR_LIST (CURRENT. SECTOR) . NEXT-SECTOR ( R ) ? 

CURRENT-SECTOR  J*  CURRENT-SECTOR  aod  SECTOR'LAST  +  1* 
end  loop? 

end  SECTOR-PROCESS I N6-C0NTR0LLER $ 


--  The  task  type  TRACK. WHILE-SCAN  (2.2.3)  is  the  heart  of  the 

—  tracking  process. 

—  One  task  of  this  type  will  process  reports  for  each  sector  of  the  radar 

—  converage  area. 

—  <><><><><><><><><><><>  NORMAL  OPERATION  <><><><><><><><><><><><><><><><> 

After  a  rendezvous  with  the  SECTOR-PROCESSING-CONTROLLER  to  obtain  a 

—  sectors  worth  of  radar  reports?  TRACK-WHILE-SCAN  aakes  calls  to  perfora 

—  the  basic  radar  report  processing  seauence*  correlation?  association? 

—  SMOOTHING  and  prediction.  TRACK-WHILE-SCAN  can  also  be  told?  via 

—  rendezvous  with  SECTOR-PROCESSING-CONTROLLER?  to  stop  current 

—  processing  and  proceed  iaaediately  to  prediction 

task  type  TRACK-WHILE-SCAN  is  —(2.2.3) 

entry  NEXT.SECTOR( R  J  in  RADAR-REPORT-BUFFER) ? 
entry  STOP? 

end  TRACK-WHILE-SCAN? 

task  body  TRACK-WHILE-SCAN  is 
R  J  RADAR-REPORT-BUFFER  I 

begin 

loop 
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select 

when  STOP' COUNT  =  0  => 

accept  NEXT_SECTOR<R  J  in  RADAR-REPORT-BUFFER)  do 
PROCESS-SECTOR (R > )  —  initiate  seauence 
end) 
or 

accept  STOP  do 

BE6IN-PREDXCTI0N)  —  begin  prediction  immediately 
end) 

end  select) 
end  loop) 


end  TRACK-UHILE-SCAN) 


<><><><><><><><><><><>  TASK  RIE  <><><><><><><><><><><><><><><><><><><><><> 

The  task  RIE  sioulates  the  radar  interface  eeuipteent  hardware*  It 
sends  'pulses*  to  the  SECTOR-PROCESSINO-CONTROLLER  to  signal  the  end 
of  start  up  procedures  and  to  signal  the  change  of  sector.  Since  the 
RIE  acts  as  a  easter  clock  for  sector  processing  it  contains  a  start 
entru  point  to  allow  it  to  be  started  by  the  test  driver. 

task  RIE  is 

entry  START) 
end  RIE) 

task  body  RIE  is 

besin 


—  simulate  radar  hardware  activation 
accept  START) 

—  simulate  completion  of  radar  hardware  warm-up 
SECTOR-PROCESSING-CONTROLLER . R1E-ST ART. UP-DONE) 

—  simulate  first  north  sector  pulse  transmission 


SECTOR-PROCESS IN6-C0NTR0LLER  *  NORTH. SECTOR-PULSE ) 


loop 


—  simulate  sector  change  pulse  and  pass  radar  report  buffer 
SECTOR-PROCESS I NG-CONTROLLER.NEW-SECTOR-PULSE  <  R> ) 

—  delay  one  sector  scan  time 
end  loop* 

end  RIEI 

—  <><><><><><><><><><><><>  PACKAGE  TRACK-STORES  <><><><><><><><><><><><> 

The  track  stores  package  contains  the  track  storage  file  and  the 

—  access  entry  points  to  the  file*  Based  on  the  POL  for  the  track 

—  while  scan  functions  entries  to  read  and  write  one  track  record  and 

—  entries  to  read  and  write  one  sector  have  been  provided 


package  TRACK-STORES  is  --(2.3.2) 


task  PILE-MGR  is  —  (2.3.) 


entry  READ-SECTOR  <S  J  in  SECTOR-NO) 
entry  URITE-SECTOR(S  i  in  SECTOR-NO) 
entry  READ  <S  *.  in  SECTOR-NO)  T  t  in 
entry  URITE(S  i  in  SECTOR.NO)  T  :  in 


D  J  out  SECTOR-DATA)) 

D  t  in  SECTOR-DATA)) 

TRACK-NO)  R  *.  out  TRACK-RECORD)) 
TRACK. NO)  R  )  in  TRACK-RECORD)) 


end  FILE-NGR ) 


type  TRACK-RECORD  is 
RECORD 

STA  iSTATUS) 

SEC. NO  l SECTOR-NO) 

TK-NO  .TRACK-NO) 

EXISTS  .BOOLEAN) 

PRED-POS  5  PREDICTED-POS ) 

S.POS  tSMOOTHED-POS) 

VEL  JSNOOTH.MEL)  —THE  PREDICTED  VELOCITY 

ALT  tALTITUDE)  —THE  PREDICTED  ALTITUDE 

INDEX  .SMOOTHING- INDEX) 

RGATE  $  BOOLEAN) 

OUTGATE  .BOOLEAN) 

ALTGATE  ) ALTITUDE-GATE) 

A-CNT  tASSOCIATION-CQUNT) 
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T  :time-of_last_smoothing? 

D-VEC  jdeviation-vector? 

CONSEC  J CONSEC-HIT  ? 

END  record; 


type  SECTOR-DATA  is  arraytTRACK-NO'FIRST. .TRACK-NO 'LAST)  of  TRACK-RECORD? 

end  TRACK-STORES? 

PACKAGE  VECTOR-OPERATIONS-PDL  IS 

—  THIS  PACKAGE  MUST  OVERLOAD  THE 

—  BINARY  OPERATORS  OF  '+'  AND  TO  ALLOW  THE  CAPABILITY 

—  OF  OPERATING  ON  VECTORS  OF  TWO  DIMENTIONS  AND  RETURN 

—  THE  SAME  TYPE. 

—  ADDITIONALLY  IT  MUST  PROVIDE  THE  CAPABILITY  TO  OVERLOAD 

—  THE  BINARY  OPERATOR  TO  ALLOW  FOR  MULTIPLICATION  OF 

--  A  FLOATING  POINT  SCALAR  TYPE  AND  A  VECTOR  OF  TWO  DIMENSIONS. 


TYPE  VECT  IS 
RECORD 
XJ FLOAT? 

YJFLOAT? 

END  RECORD? 

FUNCTION  •+’  (AfBJVECT)  RETURN  VECT? 
function  <a;float?b:vect>  RETURN  VECT? 
FUNCTION  *-■  (AfBJVECT)  RETURN  VECT? 

END  VECTOR-OPERATIONS? 


PACKAGE  TRACKING.OPERATIONS.PDL  IS 

—  THIS  PACKAGE  CONTAINS  THE  FUNCTIONS f  PROCEDURES  AND  TYPES  REQUIRED 

—  BY  THE  SMOOTHING  AND  PREDICTION  MODULES  OF  THE  TRACK-WHILE-SCAN 

—  TASKS.  THESE  PROCESSES  REQUIRE  KNOWLEDGE  OF  THE  RECORD  COMPONENTS  OF 

—  OF  THE  TRACK-STORAGE-FILE.  THE  PACKAGE  TRAKE-STORES  CONTAINS  A 


—  DEFINITION  OF  THE  TRACK. RECORD  AND  SHOULD  BE  REFERRED  TO  WHEN 

—  GENERATING  THE  CODE  FOR  THIS  PACKAGE » 

—  THE  OBJECTIVE  OF  THIS  PACKAGE  IS  TO  DEFINE  THE  FUNCTIONS  REQUIRED 
~  FOR  THE  TRACKING  OPERATIONS  AND  THEIR  INTERFACES.  TO  AID  THIS 

—  DEVELOPMENT  THE  ADA  TYPES  REQUIRED  BY  THESE  OPERATIONS  ARE  ALSO 

—  DEFINED.  THIS  PACKAGE  MAY  BE  COMPILED  BUT  IT  IS  NOT  INTENDED  TO  BE 

—  EXECUTED. 

TYPE  VECT  IS 
RECORD 

X'.MFLOAT? 

Y*.  FLOAT? 

END  RECORD? 

SUBTYPE  DEV I AT I ON. VECT  IS  VECT? 

SUBTYPE  PREDICTED.POS  IS  VECT? 

SUBTYPE  SMOOTH.POS  IS  VECT? 

SUBTYPE  SMOOTH.VEL  IS  VECT? 

SUBTYPE  REPORT.POS  IS  VECT? 

SUBTYPE  ALTITUDE-GATE  IS  INTEGER  RANGE  ALTITUDE-GATE 'FIRST. . 
ALTITUDE-GATE 'LAST? 

TYPE  TRACK-NO  IS  NEW  INTEGER  RANGE  1..512? 

TYPE  SECTOR-NO  IS  NEU  INTEGER  RANGE  1..20? 

TYPE  REPORT-NO  IS  NEU  INTEGER  RANGE  1..512? 

TYPE  SMOOTHING-INDEX  IS  NEU  INTEGER  RANGE  1..5? 

TYPE  SMOOTH-CONSTANTS  IS 
RECORD 

POS  l  FLOAT? 

VEL  :  FLOAT? 

END  RECORD? 

SMOOTH-TABLE  i  CONSTANT  ARRAY  < SMOOTHING-INDEX)  OF  SMOOTH-CONSTANTS  t* 

< (0.4373*0.625) » 

(0.3625*0. 1875) * 


(0,8125.0.4375) » 

(0,9375.0.5625) ) ? 

A  TYPE  OF  'TIME'  MUST  BE  DEFINED  AT  THIS  POINT 
THE  FORMAT  FOR  'TIME'  SHOULD  PROVIDE  THE  CAPABILITY  TO 
DETERMINE  THE  CURRENT  SYSTEM  TIME  NECESSARY  FOR  CALCULATIONS 
BELOW 

««<  FUNCTIONS  REQUIRED  BY  TRACKING  COMPONENTS  »»> 

FUNCTION  DET_DEVIATION_VECT  (A:REPORT_POS?B:PREDICTED_POS) 
RETURN  DEVIATIQN-VECT ? 

FUNCTION  SMOCONdt  SMOOTHING. INDEX )  RETURN  SMOOTH-CONSTANTS? 


««<  PROCEDURES  REQUIRED  BY  TRACKING  COMPONENTS  »»> 


PROCEDURE  PREDICTION  (XJ  IN  SECTOR-NO)?  —  (2. 2. 3. 4) 

—  ONCE  PER  RADAR  SCAN  EACH  TRACK  IN  EACH  SECTOR  SHALL  BE  DEAD 

—  RECONED  FORWARD  TO  A  POSITION  WHERE  THE  RADAR  EXPECTS  TO 

—  FIND  THE  TRACK  ON  THE  SUBSEQUENT  SWEEEP 

—  THIS  SHALL  BE  ACCOMPLISHED  BY  READING  IN  ALL  THE  TRACKS 

—  FROM  THE  CURRENT  SECTOR  OF  THE  TRACK  STORAGE  FILE 

—  AND  PROCESSING  THE  TRACKS  FROM  THAT 

—  SECTOR  SEQUENTIALLY 

—  THE  FORMULA  THAT  SHALL  BE  USED  TO  PREDICT  THE  TRACK'S 

—  POSITION  IS  AS  follows: 

PREDICTED  POSITION  *  SMOOTHED-POSITION  +  (RADAR-SCAN-TIME 
+  CURRENT-TIME)  *  SMOOTHED -VELOCITY 

—  AFTER  ALL  T7ACKS  IN  THE  CURRENT  SECTOR  HAVE  BEEN  PREDICTED 

—  THE  CURRENT  SECTOR  OF  THE  TRACK  STORAGE  FILE  SHALL  BE  UPDATED 


PROCEDURE  SMOOTHING  ( RNt  IN  REPORT-NO?  Tt  IN  TRACK-NO?  St  IN  3ECTOR-NO) 

—  (2.2.3. 3) SMOOTHING  SHALL  TAKE  PLACE  AFTER  ASSOCIATION  HAS 

—  DETERMINED  WHICH  REPORT  IS  PAIRED  WITH  A  PARTICULAR  TRACK 

—  SMOOTHING  SHALL  CONSIST  OF  SEVERAL  SEQUENTIAL  STEPS 

—  THEY  AREt 

DETERMINE  ALTITUDE  GATE 
SMOOTH  ALTITUDE  <2. 2. 3. 3. 3) 

DETECT  TRACK  MANEUVERABILITY < 2 . 2 . 3 . 3 . A ) 

SMOOTH  VELOCITY <2. 2. 3. 3. 2) 

SMOOTH  POSITIONS. 2*3. 3.1) 

—  DETERMINE  ALTITUDE  GATE 

THE  REPORT  RECORD  SHALL  BE  RETRIVED  FROM  THE  REPORT  FILE 
AND  THE  FOLLOWING  SHALL  TAKE  PLACE 

AN  ALTITUDE  GATE  SHALL  BE  FORMED  BY  ADDING  AND  SUBTRACTING 
AN  INTEGER  VALUE  TO  THE  TRACK'S  LAST  RECORDED 
ALTITUDE.  THIS  INTEGER  VALUE  IS  STORED  IN  THE  TRACK-RECORD 
IN  THE  OBJECT  ALTGATE. 

IF  THE  REPORT  ALTITUDE  LIES  INSIDE  THIS  GATE 
THEN  ALTGATE  SHALL  BE  REDUCED  BY  500  FEET 
IF  THE  REPORT  ALTITUDE  LIES  OUTSIDE  OF  THE  GATE  THEN 
THE  ALTGATE  SHALL  BE  INCREASED  BY  500  FEET. 

THE  ALTGATE  HAS  MAXIMUM  AND  MINIMUM  VALUES 
DEFINED  IN  THE  CLASSIFIED  PACKAGE. 

THEY  ARE  STORED  IN  ALTITUDE-GATE' FIRST  AND 
ALTITUDE-GATE' LAST 

SMOOTH  ALTITUDE 

IF  THE  TRACK'S  ALTGATE  IS  LESS  THAN 
ALTITUDE-GATE ' LAST  THEN 

THE  SMOOTHED  ALTITUDE  SHALL  BE  COMPUTED  BY 
THE  ARITHMETIC  MEAN  BETWEEN  THE  REPORT  ALTITUDE 
AND  THE  TRACK'S  ALTITUDE 

OTHERWISE  THE  REPORT  ALTITUDE  SHALL  REPLACE 
THE  TRACK'S  ALTITUDE. 

DETECT  TRACK  MANEUVERABILITY 

THIS  SHALL  BE  THE  EQUIVALENT  OF  DETERMINING 

THE  SMOOTHING  INDEX. 
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IF  THE  TRACKS'S  INDEX  IS  1  AND  IF  THERE  HAVE 
BEEN  TWO  CONSECUTIVE  OUTERGATE  HITS  THEN 
THE  INDEX  SHALL  BE  SWITCHED  TO  5. 

IF  THE  TRACK'S  INDEX  IS  2t2tA  OR  5  THEN 
THE  INDEX  SHALL  BE  DECREASED  BY  ONE  FOR 
A  RECOVERY  GATE  HIT  AND  INCREASED  BY 
ONE  FOR  AN  OUTERGATE  HIT. 

ALL  SMOOTHING  INDICES  SHALL  BE  RESTRICTED  TO 
A  RANGE  OF  1..5. 

SMOOTH  VELOCITY 

THE  SMOOTHED  VELOCITY  SHALL  BE  CALCULATED  ACCORDING 
TO  THE  FOLLOWING  FORMULA t 

SMOOTHED-VELOCITY  =  SMOOTHED-VELOCITY  +  (VELQCITY- 
SMOOTHING-CONSTANT/  TIME-SINCE-LAST-SMOOTHING)  *  DEV¬ 
IATION-VECTOR 

THE  VELOCITY-SMOOTHING-CONSTANT  SHALL  BE  OBTAINED  FROM 
THE  FUNCTION  SMOCON  DESCRIBED  ABOVE. 

SMOOTH  POSITION 

THE  SMOOTHED  POSITION  SHALL  BE  A  FUNCTION  OF  THE  LAST 
SMOOTHED  POSITION  AND  THE  DEVIATION-VEC  RELATED  IN  THE 
FOLLOWING  FORMULA: 

SMOOTH-POSITION  J  =  SMOOTHED-POSITION  +  POSTION-SMOOTHING- 
CONSTANT  *  DEVIATION-VECTOR 


END  TRACKING-OPERATIONS; 


PACKAGE  VECTOR-OPERATIONS-PDL  IS 

—  THIS  PACKAGE  MUST  OVERLOAD  THE 

—  BINARY  OPERATORS  OF  '+'  AND  TO  ALLOW  THE  CAPABILITY. 

—  OF  OPERATING  ON  VECTORS  OF  TWO  DIMENTIONS  AND  RETURN 

—  THE  SAME  TYPE. 

--  ADDITIONALLY  IT  MUST  PROVIDE  THE  CAPABILITY  TO  OVERLOAD 

—  THE  BINARY  OPERATOR  '*'  TO  ALLOW  FOR  MULTIPLICATION  OF 
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A  FLOATING  POINT  SCALAR  TYPE  AND  A  VECTOR  OF  TWO  DIMENSIONS 


TYPE  VECT  IS 
RECORD 

x:float; 

yjfloat? 

END  RECORD) 

FUNCTION  ■  +  ■  <A»BtVECT>  RETURN  VECTi 

function  <a:float?b:vect>  return  vect» 

FUNCTION  <A»B:VECT>  RETURN  VECTi 

END  VECTOR-OPERATIONS? 
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The  code  reproduced  in  Appendix  I  is  organized  into  the  following  ■ — ■. 

four  Ada  packages: 

1)  VECTOR_OPERATIONS 

2)  TRACK_TYPES 

3)  MANAGE_TABLES 

4)  TRACK ING_OPERAT I ON S 

Collectively,  they  represent  the  code  necessary  to  implement  the 
following  functional  areas  of  the  AN/TSQ-73: 

•  Sector  Processing  -  process  radar  reports  by  predefined  sectors 
implemented  in  Ada  by:  task  type  TRACK_WHILE_SCAN  (2.2.3). 

•  Sector  Processing  Control  -  provide  for  control  of  sector  pro- 
cessing,  its  timing  requirements,  and  synchronization  of  that 
processing  with  the  Radar  Interface  Equipment 

implemented  in  Ada  code  by:  task  SECTOR_proceSSING_CONTROLLER  in 

package  TRACKING_OPERATIONS  * 

•» 

•  Altitude  Gate  -  provides  the  measure  of  altitude  correlation 
history 

implemented  in  Ada  code  as:  a  subset  of  procedure  Smoothing  (2. 2. 3. 3) 
and  enclosed  in  comments  —  DETERMINE  ALTITUDE  GATE  £3 

•  Maneuver  Detection  and  Recovery  -  detects  the  maneuverability  of 
a  track 

implemented  in  Ada  as  a  subset  of  procedure  Smoothing  (2. 2. 3. 3) 

and  offset  with  comment  —  Maneuver  Detection  ~ 

•  Smoothing  -  the  application  of  mathematical  formulas  to  associated 

Radar  reports  in  order  to  determine  a  smoothed  position,  smoothed 
altitude  and  smoothed  velocity  while  accounting  for  the  maneuver-  L*i 

ability  of  the  track 

implemented  in  Ada  code  as  procedure  Smoothing  (2. 2. 3. 3) 

•  Prediction  -  predict  the  position  of  each  track  by  determining  the  *. 

X  and  Y  coordinates  of  where  the  radar  should  expect  to  find  the 

track  on  the  subsequent  sweep 

implemented  in  Ada  code  as  procedure  Prediciton  (2.2. 3.4) 
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In  addition  to  these  explicit  requirements  these  implicit  functional 
areas  were  also  coded: 

•  Table  Manager  provides  authorized  access  to  the  Track  Storage 
File  while  guarding  against  conflicting  access  requests. 

implemented  in  Ada  code  by:  task  FILE_MGR  in  package  MANAGER_ 
TABLES  (2.3.2) 

•  Support  Routines  -  routines  to  support  the  mathematical  calcu¬ 
lations  of  Smoothing  and  Prediction 

implemented  in  Ada  code  as:  package  VECTOR_OPERATIONS  (would  reside 
in  the  USER  APPLICATION  LIBRARY  (1.4)). 

The  following  is  a  brief  description  of  the  contents  of  each  of  the 
four  packages: 

VECTOR_OPERATI ONS 

Defines  an  Ada  record  type  named  VECT  consisting  of  two  com¬ 
ponents  X  and  Y.  Overloads  the  operations  and 

to  allow  operations  on  objects  of  type  VECT. 

TKACKJTYPES 

Defines  the  subtypes,  enumeration  types,  records  and  arrays 
required  by  package  TRACK INGJDPERATI ONS;  the  TRACK_RECORD , 

REPORT,  REPORT_FILE ,  et  al. 

MANAGEJTABLES 

Defines  the  TRACK_STORAGE_F I LE  and  a  task  FILE_MGR  which 
provides  the  access  mechanism  described  earlier. 

TRACK ING_OPERAT IONS 

Defines  the  task  SECTOR_PROCESSING_CONTROLLER  the  task  type 
TRACK_WH I LE_SCAN  procedure  SMOOTHING,  procedure  PREDICTION, 
and  other  subprograms  required  .by  these  two  procedures. 

For  testing  purposes,  each  package  was  considered  to  be  a  unit. 

Since  packages  are  passive,  it  was  necessary  to  create  an  Ada 
procedure  for  testing  each  unit  utilizing  the  subprograms  and 
tasks  of  that  package  and  check  the  results  manually.  TKACKJTYPES 
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was  not  considered  for  its  own  unit  test  since  it  contained  only 
definitions.  It  was,  however,  included  in  other  unit  tests  since 
they  required  the  types  defined  there. 

The  task  SECTOR_PROCESSING_CONTROLLER  and  the  twenty  objects  of 
task  type  TRACK_WHILE_SCAN  from  the  package  TRACKINGJDPERATIONS 
were  considered  as  one  unit  for  testing.  They  were  grouped  to¬ 
gether  as  a  single  unit  since  they  perform  numerous  rendevous 
with  each  other,  for  this  reason  individual  testing  would  be  meaningless 
if  not  impossible.  This  test  required  the  most  time  and  effort 
since  a  third  task  simulating  the  pulses  from  radar  interface 
equipment  names  task  RIE  had  to  be  generated  in  order  to  activate 
the  SECTOR_PROCESS ING_CONTROLLER . 

A  test  procedure  with  embedded  PUT  statements  shows  when  pulses  are 
sent,  received  and  when  processing  for  sector  commences  and  termin¬ 
ates. 

The  package  VECTOR_OPERATIONS  was  also  tested  as  a  unit.  An  Ada 
procedure  was  written  declaring  objects  of  type  VECT  with  ini¬ 
tialized  values.  The  objects  were  then  operated  on  using  the 
overloaded  operations  and  the  results  were  checked  manually. 

Since  Smoothing  and  Prediction  both  required  the  package  VECTOR_ 
OPERATIONS,  TRACKJTYPES,  and  MANAGE_TABLES  a  unit  test  for  each 
was  discarded  in  favor  of  testing  the  four  packages  together. 

At  the  time  of  this  writing,  the  test  code  was  being  generated 
according  to  the  following  plan. 

The  task  RIE  (mentioned  earlier)  will  activate  the  SECTOR_PROCESSING_ 
CONTROLLER  by  simulating  pulses  from  tue  radar.  The  SECTOR_PROCESSING_ 
CONTROLLER  will  activate  and  terminate  according  to  the  timing 
requirements  the  twenty  TRACK_WHILE_SCAN  tasks.  Smoothing  and 
Prediction  will  operate  within  each  TRACK_WHILE_SCAN  task  on  simu¬ 
lated  data.  The  data  will  reside  in  three  files,  the  TRACK_STORAGE_ 
FILE,  which  contains  track  records,  the  ASSOCIATED_REPORT_FILE  which 
contains  report  to  track  pairs,  and  the  REPORT_FILE  which  contains 
radar  reports.  Since  Smoothing  and  Prediction  affect  the  TRACK_ 
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STORAGE_FILE,  this  file  will  be  printed  before  the  simulation  action 
and  afterwards  by  means  of  a  procedure  SNAPSHOT.  The  calculations 
can  then  be  checked  manually. 

The  following  tables  illustrate  the  test  output  produced  for  one 
track  during  the  processing  of  one  radar  scan.  The  table  items 
are  the  components  of  the  track  storage  file  that  are  manipulated 
by  the  radar  processing  algorithms. 


TRACK  STORAGE  FILE  BEFORE 


SEIECTQR  NUMBER 

1 

TRACK  NUMBER 

1 

STATUS 

Local 

PREDICTED  POSITION 

(16,99) 

PREDICTED  VELOCITY 

(0, .25) 

ALTITUDE 

10,000 

ALTITUDE  GATE 

5,000 

SMOOTHED  POSITION 

(16,98.75) 

SMOOTH  INDEX 

TIME 

5 

R-GATE 

T 

OCTERGATE 

F 

CONSECUTIVE  HITS 

0 

ASSOCIATION  COUNT 

6 

DEVIATION  VECTOR 


(0.0,25) 


TRACK  STORAGE  FILE  AFTER  SNAPSHOT 


SELECTOR  NUMBER 

1 

TRACK  NUMBER 

1 

STATUS 

Local 

PREDICTED  POSITION 

(16,100.2551) 

PREDICTED  VELOCITY 

(00.2573) 

ALTITUDE 

9,500 

ALTITUDE  GATE 

4,500 

SMOOTHED  POSITION 

(16,97.8313) 

SMOOTH  INDEX 

TIME 

4 

R-GATE 

T 

OUTERGATE 

F 

CONSECUTIVE  HITS 

0 

ASSOCIATION  COUNT 

6 

DEVIATION  VECTOR 

(00,0.1) 
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The  listing  for  the  procedure  required  to  test  the  package 
VECTOR_OPERATIONS  follows.  The  procedure  declared  objects 
of  type  VECT  and  assigned  an  initial  value  to  each. 


The  overloaded  operators  were  then  tested  by  performing  the 
given  operations  on  these  objects  and  verifying  the  results. 
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♦  ad  a  tnialh.ada 

k-i 

l 


NYU  Ada/ED  16.3(5/29/82) 


THU  10  JUN  82  12103:36 


ADAfile5  TMATH.ADA 


1  with  TEXT-10)  use  TEXT-10) 

2 

3 

4  procedure  TEST-VECTOR-OPERAT I ONS  is 

5 

6  package  F  is  NEW  FLOAT-I 0 ( FLOAT >5 use  F ) 

7 


8 

package  VECTOR-OPERATIONS  is 

9 

10 

tape  VECT  is 

11 

record 

12 

X1FL0AT) 

13 

yifloat; 

14 

end  record) 

15 

16 

function  *+*  (A*BSVECT) 

return  VECT) 

17 

function  ’*•  ( A: FLOAT ) B J VECT > 

return  VECT) 

18 

function  *-*  (A*BSVECT) 

return  VECT) 

19 

20 

end  VECTOR-OPERATIONS* 

21 

22 

package  BODY  VECTOR-OPERATIONS  is 

23 

24 

function  *+*  (A*BJVECT)  return 

VECT  is 

25 

begin 

26 

return  <  (X  =>  A.X  +  B.X* 

FACE 
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Y  =>  A.Y  +  B . Y  >  > } 


function  *<■  < A J FLOAT } B J VECT )  return  VECT  is 
bedin 

return  <  (X  =>  A  *  B.X» 

Y  =>  A  *  B. Y> ) } 


function  *-*  (A.B'.VECT)  return  VECT  is 


beSin 

return  ((X  =>  A.X  -  B.X. 

Y  =>  A.Y  -  B .  Y )  )  } 


end  VECTOR-OPERATIONS} 
use  VECTOR-OPERATIONS} 
M:VECTJ=(0. 5.0.25) } 
n:vect:=<-3.5»4. i ) » 

Rf S.T.U.VJ VECT} 
x:float:=5.2} 


beSi  n 

r:=m+n} 

S:=M-N} 

t:=n-m} 
u:=x*m} 
v: =x*N} 
F'UT  <  •«=*)} 
PUT ( *  N=  * ) } 
PUT ( ’X=*  )  } 


F.PUT(M.X)  } 
F.FUT(N.X)  } 
F  •  F’UT  <  X  ) » 


F.PUT(M.Y)}  new. line 
F.F'UT(N.Y)}  new_  line 
new- line} 


F'UT  <  *  H+N=  *  )  }  F.PUT(R.X)}  F.F'UT(R.Y)}  new.line 


POT ( *  M  -  N  =  " ) *  F.PUT(S.X)} 
PUT  ( *  N-M=  '  )  )  F.F'UT(T.X)} 


F  .  F'UT  (  S  .  Y  )  }  new.  line 
F . PUT ( T . Y ) }  new-line 


67 

FUT<  *X*M=* ) 5 

F . PUT ( U • X ) » 

F.PUT(U.Y) i 

neu.l ine 

68 

PUT ( *  X*N=  * ) i 

F.PUT(V.X) i 

F.PUT(V.Y) i 

new.line 

69 

end  i 

70 

no  parse  errors  detected 
Parsins  tine!  99  seconds 

«  i 


no  semantic  errors  detected 
Translation  time!  145  seconds 


Bind ins  time!  0.9  seconds 


Besin  Ada  execution 


H=5. 00000 OE-012.500000E-01 
N=-3.500000E+004. 100000E+00 
X*5.200000E+00 

M+N=-3.000000E+004 .350000E+00 
H-H*4.000000E+00-3.850000E+00 
N-H*-4.000000E+003.850000E+00 
X*M  =  2 . 600000E+001 . 300000E+00 
XtN«- 1 .820000E+012. 1 32000E+01 

Execution  complete 
Execution  time!  137  seconds 
I-code  statements  executed:  146 
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On  the  succeeding  pages  is  the  code  and  the  results  of  the  exe¬ 
cution  of  the  code  that  tests  the  task  SECTOR_PROCESSING_CONTROLLER 
and  the  twenty  tasks  TRACK_WHILE_SCAN.  Pulses  from  the  Radar 
Interface  Equipment  are  simulated  to  activate  the  task  SECTOR_ 
PROCESSING_CONTROLLER.  The  SECTOR_PROCESSING_CONTROLLER  then 
synchronizes  the  TRACK_WHILE_SCAN  tasks.  The  results  indicate 
when  processing  for  a  current  sector  has  begun  and  for  which 
sector  stop  orders  have  been  sent.  Also  indicated  are  the  sending 
and  receiving  of  the  new  sector  pulses.  The  file  name  used  for  the 
test  procedure  was  C0DE2.ADA.  The  results  are  found  in  C0DE2.AIS. 


♦  TYPE  C0DE2.ADA 

with  TEXT_IO »  use  TEXT-IO, 

package  TRACKING-DATA  is 

subtype  SECTOR  is  INTEGER  range  1..205 

subtype  RADAR_REPORT_BUFFER  is  INTEGER  range  1..20J 

package  BUFF-IO  is  new  INTEGER- 1 0 ( RADAR_REPORT_BUFFER ) i  use  BUFF-IO 
package  SECTOR-IO  is  new  I NTEGER- 1 0 ( SECTOR ) i  use  SECTOR-IO; 

task  type  TRACK-WHILE-SCAN  is 

entry  NEXT-SECTOR ( R  t  in  R A DAR-RE PORT-BUFFER) » 
entry  STOP(R  J  in  RADAR-REPORT-BUFFER); 
end  TRACK-UHILE-SCAN; 


end  TRACKING-DATA;--  SPEC 
package  body  TRACKING- DAT A  is 

task  body  TRACK -WHILE-SCAN  is 

begin 

loop 

select 

when  STOP 'COUNT  =■  0  => 

accept  NEXT-SECTOR  <  R  J  in  RADAR_REPORT_BUFFER  >  do 

PUT ( *  PROCESSOR  a  *>; 

BUFF_I0. PUT(R>  » 

PUT_LINE  <  '  ACCEPTING  NEW  DATA*); 
end  f 
or 

accept  STOP1  ( R  J  in  R A D A R _ R E P 0 R T _ B U F F E R  )  do 

PUT ( *  PROCESSOR  b  *>; 

BUFF-IO. PUT<R ) ; 

PUT_LINE<  *  ACCEPTING  STOP  COMMAND* >i 
end  t 

end  select; 
end  loop; 


end  TRACK-UHILE-SCAN; 


BODY 


end  TRACKING. DATA; 


with  TRACKING-DATAiuse  TRACK  I NG.DAT A i 
with  TEXT.IO;  USE  TEXT.IO; 
package  TRACKING  is 


task  RIE  is 

entry  START; 
end  RIEi 

task  SECTOR .PROCESS I NG.CONT ROLLER  is 
entry  R IE.ST ART.UP.DONE ; 
entry  NORTH_SECTOR_PULSE ; 

entry  NEU.SECTOR.PULSE (R  J  in  RADAR-REPORT -BUFFER > » 
end  SECTOR-PROCESSING .CONTROLLER; 

end  TRACKING;  --  SPEC 

rackaae  body  TRACKING  is 

task  body  SECTOR.PROCESSING-CONTROLLER  is 

PROCESSOR-LIST  5  array  ( SECTOR ' FIRST .. SECTOR ' LAST  )  of  TRACK-WHILE -SCAN 
R  J  RADAR_REPORT_BUFFER; 

CURRENT-SECTOR  J  SECTOR  :=  i; 


accept  RIE-START-UP.DONE  do 

PUT-LINE ( *  R I E_ST ART-UP -DONE  RECEIVED* >; 

end ; 


accept  NORTH-SECTOR-PULSE  do 

PUT.LINEC  NORTH_SECTOR_PULSE  RECEIVED*); 

end  * 


loop 

accept  NEW_SECTOR.PULSE<R  :  in  RADAR_REPORT_RUFFER )  do 

PUT  <  *  NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  *>; 

BUFF. 1 0 . PUT ( R ) ;  NEW. LINE; 
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—  terminate  task  frocessiftfl  three  sectors  "ahead*  of  current  sector 
PUT ( *  STOP  ORDER  SENT  FOR  PROCESSOR  *)? 

SECTOR-IO.PUT ( <CURRENT_SECTOR  4  2)  mod  SECTOR'LAST  4  1)5  NEW-LINE  * 
PROCESSOR_LIST( (CURRENT-SECTOR  4  2)  mod  SECTOR'LAST  4  1>.ST0P< 
(CURRENT-SECTOR  4  2)  mod  SECTOR'LAST  41)5 

--  initiate  task  to  process  the  sector  data  Just  received 
PUT ( *  PROCESSOR  STARTED  FOR  ">5 

SECTOR-IO.PUT  (CURRENT-SECTOR) 5  NEW-LINE  5 
PROCESSOR-LIST ( CURRENT- SECTOR ) . NEXT-SECTOR ( R ) 5 
end  $ 

CURRENT-SECTOR  J=  CURRENT-SECTOR  mod  SECTOR'LAST  4  15 
end  loopf 

end  SECTOR-PROCESSING-CONTROLLER  5 


task  bodv  RIE  is 

TEST-DUFFER  .*  RADAR_REFORT_BUFFER  5 
COUNT  :  SECTOR  5 


besin 


accept  START  do 

PUT_LINE( "RIE  TURNED  ON  d  *>5 
end 5 


COUNT  !=  SECTOR ' FIRST  5 

TEST-BUFFER  J*  RADAR-REPORT-BUFFER ( COUNT ) 5 

PUT_LINE( "RIE-START-UF-DONE  SENT"  )  5 
SECTOR-PROCESSING-CONTROLLER. RIE_ ST ART- UP -DONE  5 

PUT_LINE( "NORTH  SECTOR  PULSE  SENT " ) 5 

SECTOR -PROCESSING-CONTROLLER. NORTH -SECTOR-PULSE  5 

1  OOP 

FUT( "NEW-SECTOR-PULSE  SENT  FOR  ">5 
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SECTOR-IO.PUT (COUNT) »  NEW-LINE  $ 

SECTOR-PROCESSING-CONTROLLER. NEW- SECTOR-PULSE (TEST -BUFFER) 

COUNT  J=  COUNT  mod  SECTOR ' LAST  +  If 

TEST-BUFFER  J=  RADAR-REPORT-BUFFER ( COUNT ) » 
end  1 ooe  > 
end  RIE; 
end  TRACKING; 

with  TRACKING;  use  TRACKING; 
with  TRAC KING -DAT A ; use  TRACKING-DATA; 
with  TEXT-IOJ  USE  TEXT-IO; 
procedure  TEST  is 
task  TEST-DRIVER  f 

task  body  TEST-DRIVER  is 
begin 

put_line< "task  TEST-DRIVER  ENTERED’ >; 

RIE. start; 

put_l  ir.e  (  *  RIE  TURNED  ON  e  ’>; 

DELAY  25000.0;—  8  HR 
PUT_LINE C  task  TEST-DRIVER  ENDS  ’>; 
end  TEST-DRIVER; 
begin 

PUT-LINE< ’PROCEDURE  TEST  ENTERED’ >; 

end  TEST; 
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NYU  Ada/ED  16.3(5/29/82) 


THU  10  JUN  82  09  5  49 : 32 


AISfile:  C0DE2.AIS 


Binding  time!  2.0  seconds 


Besin  Ada  execution 


task  TEST-DRIVER  ENTERED 
RIE  TURNED  ON  d 
PROCEDURE  TEST  ENTEIED 
RIE  TURNED  ON  e 
R I E-START-UP-DONE  SENT 

RIE_START_UP_DONE  RECEIVED 
NORTH  SECTOR  PULSE  SENT 

NORTH_SECTOR_PULSE  RECEIVED 
NEU-SECTOR-PULSE  SENT  FOR  1 

NEU  SECTOR  PULSE  RECEIVED  FOR  SECTOR  1 
STOP  ORDER  SENT  FOR  PROCESSOR  4 

PROCESSOR  b  4  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  1 

3I»H>.  PROCESSOR  a  1  ACCEPTING  NEW  DATA 

tjNE Id _SEC TOR -PULSE  SENT  FOR  2 

NEU  SECTOR  PULSE  RECEIVED  FOR  SECTOR  2 
.  STOP  ORDER  SENT  FOR  PROCESSOR  5 

PROCESSOR  b  5  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  2 

PROCESSOR  a  2  ACCEPTING  NEW  DATA 

NEU-SECTOR-PULSE  SENT  FOR  3 

NEU  SECTOR  PULSE  RECEIVED  FOR  SECTOR  3 
STOP  ORDER  SENT  FOR  PROCESSOR  6 

PROCESSOR  b  6  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  3 

PROCESSOR  a  3  ACCEPTING  NEW  DATA 

NEU-SECTOR-PULSE  SENT  FOR  4 


PAGE  1 
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NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  4 
STOP  ORDER  SENT  FOR  PROCESSOR  7 

PROCESSOR  b  7  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  4 

PROCESSOR  a  4  ACCEPTING  NEW  DATA 

NEW-SECTOR-PULSE  SENT  FOR  5 

.  NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  5 

STOP  ORDER  SENT  FOR  PROCESSOR  8 

PROCESSOR  b  8  ACCEPTING  STOP  COMMAND 
L,  PROCESSOR  STARTED  FOR  5 

PROCESSOR  s  5  ACCEPTING  NEW  DATA 

NEW-SECTOR-PULSE  SENT  FOR  6 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  6 
STOP  ORDER  SENT  FOR  PROCESSOR  9 

PROCESSOR  b  9  ACCEPTING  STOP  COMMAND 
w  PROCESSOR  STARTED  FOR  6 

<  PROCESSOR  3  6  ACCEPTING  NEW  DATA 

NEW -SEC TOR -PULSE  SENT  FOR  7 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  7 
STOP  ORDER  SENT  FOR  PROCESSOR  10 

PROCESSOR  b  10  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  7 

PROCESSOR  3  7  ACCEPTING  NEW  DATA 

NEW-SECTOR-PULSE  SENT  FOR  8 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  8 
S  STOP  ORDER  SENT  FOR  PROCESSOR  11 

PROCESSOR  b  11  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  8 

PROCESSOR  3  8  ACCEPTING  NEW  DATA 

NEW-SECTOR_PULSE  SENT  FOR  9 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  9 
STOP  ORDER  SENT  FOR  PROCESSOR  12 

PROCESSOR  b  12  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  9 

PROCESSOR  s  9  ACCEPTING  NEW  DATA 

NEW-SECTOR-PULSE  SENT  FOR  10 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  10 
STOP  ORDER  SENT  FOR  PROCESSOR  13 

PROCESSOR  b  13  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  10 


PROCESSOR  a  10 

NEW-SECTOR-PULSE  SENT  FOR  11 

NEU  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR 
PROCESSOR  b  14 

■  .  PROCESSOR  STARTED  FOR  11 

PROCESSOR  a  11 

NEU-SECTOR-PULSE  SENT  FOR  12 

NEW  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR- 
PROCESSOR  b  15 
PROCESSOR  STARTED  FOR  12 

PROCESSOR  a  12 

NEW-SECTOR-PULSE  SENT  FOR  13 

NEU  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR 
PROCESSOR  b  16 
PROCESSOR  STARTED  FOR  13 

PROCESSOR  a  13 


NEW-.SECTOR-PULSE  SENT  FOR  14 

NEU  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR 
PROCESSOR  b  17 
PROCESSOR  STARTED  FOR  *4 

PROCESSOR  a  14 


NEU-SECTOR-F'ULSE  SENT  FOR  15 

NEW  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR- 
PROCESSOR  b  18 
PROCESSOR  STARTED  FOR  15 

PROCESSOR  a  15 


NEU_SECT OR -PULSE  SENT  FOR  16 

NEU  SECTOR  PULSE  RECEIVED  FOR 
STOP  ORDER  SENT  FOR  PROCESSOR 
PROCESSOR  b  19 
PROCESSOR  STARTED  FOR  16 

PROCESSOR  a  16 


NEU_SECTOR_FULSE  SENT  FOR  17 

NEU  SECTOR  PULSE  RECEIVED  FOR 
5  STOP  ORDER  SENT  FOR  PROCESSOR 


ACCEPTING  NEU  DATA 

SECTOR  11 

14 

ACCEPTING  STOP  COHMANDi 

ACCEPTING  NEU  DATA 

SECTOR  12 

15 

ACCEPTING  STOP  COMMAND 

ACCEPTING  NEU  DATA 

SECTOR  13 

16 

ACCEPTING  STOP  COMMAND 

ACCEPTING  NEU  DATA 

SECTOR  14 

17 

ACCEPTING  STOP  COMMAND 

ACCEPTING  NEU  DATA 

SECTOR  15 

18 

ACCEPTING  STOP  COMMAND 

ACCEPTING  NEU  DATA 

SECTOR  16 
19 

ACCEPTING  STOP  COMMAND 

ACCEPTING  NEU  DATA 

SECTOR  17 

.0 
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PROCESSOR  b  20  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  17 

PROCESSOR  a  17  ACCEPTING  NEW  DATA 

NEW_SECTOR_PULSE  SENT  FOR  18 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  18 
STOP  ORDER  SENT  FOR  PROCESSOR  1 

PROCESSOR  b  1  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  18 

PROCESSOR  a  18  ACCEPTING  NEW  DATA 

NEW-SECTOR- PULSE  SENT  FOR  19 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  19 
STOP  ORDER  SENT  FOR  PROCESSOR  2 

PROCESSOR  b  2  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  19 

PROCESSOR  3  19  ACCEPTING  NEW  DATA 

NEW_SECTOR_ PULSE  SENT  FOR  20 

^EW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  20 
STOP  ORDER  SENT  FOR  PROCESSOR  3 

PROCESSOR  b  3  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  20 

PROCESSOR  3  20  ACCEPTING  NEW  DATA 

NEW- SECT OR_PULSE  SENT  FOR  1 

NEW  SECTOR  PULSE  RECEIVED  FOR  SECTOR  1 
STOP  ORDER  SENT  FOR  PROCESSOR  4 

PROCESSOR  b  4  ACCEPTING  STOP  COMMAND 
PROCESSOR  STARTED  FOR  1 

PROCESSOR  3  1  ACCEPTING  NEW  DATA 


NEW_SECTOR_PULSE  SENT  FOR  2 


The  file  QCODE.ADA  contains  the  four  packages  described 
in  the  beginning  of  this  appendix. 


Ada/ED  16.3(5/29/82)  TUE  22  JUN  82  08:54544 

QCODE . ADA 
QCODE.AIS 

1 

2  package  VECTOR_OPERATIONS  is 

3 

4  — This  package  defines  a  tape  VECT  which  can  be  viewed  loSicalla 

5  — as  an  ordered  pair  (X»Y). 

6  — The  functions  '+'  and  ' - '  have  been  overloaded  to  allow  the 

7  — operations  of  addition  and  subtraction  on  object  of  this  tape. 

8  — The  function  has  been  overloaded  to  allow  multiplication 

9  — of  objects  of  tape  FLOAT  and  objects  of  tape  VECT.  NOTE*  This 

10  — is  left  hand  multiplication  onla. 

11  — Users  of  this  package  maa  declare  objects  of  tape  VECT  and  FLOAT 

12  — and  perform  these  operations  without  concerning  themselves  with 

13  — the  details  of  implementation. 

14  — This  package  would  reside  in  the  USER  APPLICATION  LIBRARY  (1.4) 


15 

16 
17 

ie 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 
29 


—of  COMMAND  and  CONTROL  (1.0). 


type  VECT  is 
record 

X  J  FLOAT  ? 

Y  J  FLOAT ? 
end  record? 

function  •+*  (AfBJVECT)  return  VECT? 

function  •*'  (A{FL0AT?B5 VECT)  return  VECT? 
function  *-*  ( A » B * VECT >  return  VECT? 

end  VECTOR-OPERATIONS? 


30 

31 

eackade  body 

VECTOR-OPERATIONS  is 

32 

33 

function  * 

+*  <A.B:VECT>  return  VECT  IS 

34 

35 

bed  in 

36 

return 

<  <X  =>  A.X  +  B . X» 

37 

Y  =>  A.Y  +  B.Y))? 

38 

39 

end  ? 

40 

41 

function  • 

*’  (A  J  FLOAT?  B  J  VECT)  return 

42 

43 

bed  in 

44 

return 

<<X  *>  A  *  B.Xf 

45 

Y  =>  A  *  B. Y) ) ? 

46 

end? 

47 

48 

function 

*-•  < A » B  i  VECT)  return  VECT  IS 

49 

50 

bedin 

51 

return 

<(X  =>  A.X  -  B.Xf 

52 

Y  =>  A.Y  -  B  .  Y  )  )  ? 

53 

end  ? 

54 
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end  VECTOR-OPERATIONS? 


ra 


with  VECTOR-OPERATIONS?  use  VECTOR-OPERATIONS? 
with  CALENDAR?  use  CALENDAR? 


package  TRACK-TYPES  IS 


— This  package  contains  the  tape  definitions  reauired  ba  subprograms 


►**.  * 

64 

—  and  tasks  of  TRACKING-OPERATIONS. 

It  reouires  the  use  of  the 

65 

— package 

VECTOR-OPERATIONS  to 

define  subtapes  of  VECT . 

m 

r  , 

66 

- 

L 

67 

68 

subtape 

DEVIATION-VECT 

i  s 

VECT? 

— deviation  vector 

69 

subtape 

PREDICTED-POS 

is 

VECT? 

— predicted  position 

70 

subtape 

SM00TH-P0S 

is 

VECT? 

— smoothed  position 

bs 

71 

subtape 

SMOOTH-VEL 

is 

VECT? 

--smoothed  velocita 

72 

subtape 

REPORT-POS 

is 

VECT? 

--report  position 

73 

■  ‘ 

74 

subtape 

ALTITUDE-GATE 

is 

INTEGER 

range  2500.. 5000? 

1;  ■ 

75 

subtape 

ASSOCIATION-COUNT 

is 

INTEGER 

range  0..15?  --number 

- 

--of  times  a  track  has  associated 

tape  STATUS  is  (LOCAL*  REMOTE)?  --origin  of  track 


subtape 


CONSEC-HIT 


is  INTEGER  range  0..10?  — consecutive 


— hits  in  the  outergate  during  correlation 


subtape 

subtape 

subtape 

subtape 

tape 

subtape 


ALTITUDE 

TRACK-NO 

SECTOR-NO 

SMOOTHING-INDEX 

REPORT-NO 


is  INTEGER  range  1000. .20-000? 
is  integer  range  1..20? — explicit  foft  +csT 

is  INTEGER  range  1..20? 

is  INTEGER  range  1..5? 

is  range  1..20? — explicit  for  test 


RADAR-REPORT-BUFFER  is  INTEGER  range  1..20? 


tape  SMOOTH-CONSTANTS  IS 
RECORD 

POS  J  FLOAT? 

VEL  J  FLOAT? 


92 

end  RECORDS 

93 

94 

95 

SMOOTH-TABLE  {constant  array  (SMOOTHING-INDEX)  of  SMOOTH-CONSTANTS « = 

96 

( (0,4375.0.625) » 

97 

(0.5625.0.1875). 

98 

(0.6875.0.3125) . 

99 

(0.8125.0.4375) . 

100 

(0,9375.0.5625) ) ♦ 

101 

--constants  used  by  smoothin*.  Components  are  'POS' 

for  position 

102 

— 'VEL'  for  velocity. 

103 

104 

type  TRACK-RECORD  is 

105 

RECORD 

106 

STA  { 

status; 

107 

SEC-NO  : 

SECTOR.NO; 

108 

TK-NO  : 

TRACK-NO; 

109 

EXISTS  : 

boolean; 

110 

FRED-POS  { 

PREDICTED-POS; 

111 

s.pos  : 

SMOOTH-POS; 

112 

VEL  { 

SMOOTH-VEL;  —the  predicted  velocity 

113 

ALT  { 

altitude;  —the  predicted  altitude 

114 

INDEX 

SMOOTHING-INDEX; 

115 

RGATE  t 

BOOLEAN;  — 'True'  indicates  report 

correlated  du 

116 

— recovery  sate  correlation. 

117 

OUTGATE  { 

BOOLEAN;  —'True'  indicates  report 

correlated  dui?i~G- 

118 

— outerSate  correlation. 

1 19 

ALTGATE  J 

altitude_gate; 

120 

A-CNT 

ASSOCIATION-COUNT; 

121 

T  : 

TIME;  — Time  since  last  smoothins 

122 

D-VEC 

DEVIATION-VECT;  — The  deviation  vector 

• 

123 

CONSEC  { 

CONSEC-HIT;  — Consecutive  hits  in  the 

outersate . 

124 

125 

end  RECORD; 

126 

127 

type  REPORT-TRACK 

;-PAIR  is 

128 

record 

1-27 


TK-NO  :  TRACK.NO ! 
RP-NO  i  REPORT .NO % 


129 

130 

131  end  record* 

132 

133  type  REPORT  is 

134  record 

135  RN  J  REPORT.NO* 

136  SEC-NO  :  SECTOR-NO* 

137  POS  5  REPORT.POS  * 

138  ALT  J  ALTITUDEI 

139  end  record* 

140 

141  ty*»e  REPORT-FILE  is  array  (REPORT.NO)  of  REPORT! 

142  R.F  !  REPORT-FILE! 

143 

144  type  ASSOCIATED-SECTOR  is 

145  record 

146  NUH-ASSOCi  INTEGER  RANGE  1 .. INTEGER ( TRACK-NO ' LAST )  ! 

147  PAIRS  :  array (0. . 10)  of  REPORT-TRACK-PAIR! —  explicit  for  tcbT 

148  end  record! 

149 

150  type  ASSOCIATED-REPORT-FILE  is  array(SECTOR-NO)  of  ASSOCIATED-SECTOR! 

151  ARF  !  ASSOCIATED-REPORT-FILE! 

152 

153  type  SECTOR-DATA  is  array  (TRACK-NO'FIRST. .TRACK-NO'LAST)  of  TRACK-RECoRD 

154 

155  end  TRACK-TYPES!  —SPEC 

156 

157  with  TRACK-TYPES*  use  TRACK-TYPES* 

158  package  NANAGE-TABLES  is  —  (2.3.2) 

159 

160  —  <><><><><><><><><><><><>  PACKAGE  MANAGE_TABLES<><><><><><><><><><><>< 

161 

162  —  The  nanase  tables  package  contains  the  track  storage  file  and  the 

163  —  access  entry  points  to  the  file.  Based  on  the  PDL  for  the  track 

164  —  while  scan  functions  entries  to  read  and  write  one  track  record  and 

165  —  entries  to  read  and  write  one  sector  have  been  provided 
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166 

167 

168  task  FILE-MGR  is  — <2. 3) 

169  entrs  READ-SECTOR  <S  5  in  SECTOR-NO}  D  S  out  SECTOR-DATA)} 

170  entry  WRITE-SECTOR < S  J  in  SECTOR-NO.  D  J  in  SECTOR-DATA). 

171  entry  READ  (S  J  in  SECTOR-NO}  T  J  in  TRACK-NO.  R  J  out  TRACK-RECORD) 

172  entry  WRITE(S  J  in  SECTOR-NOi  T  J  in  TRACK-NO}  R  {  in  TRACK-RECORD) 


173 

174 

175 

176 

177 

178 

179 

180 
181 
182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 


end  FILE-MGR » 

type  T_S_F  is  array  (SECTOR-NO'FIRST. .SECTOR-NO'LAST. 

TRACK-NO 'FIRST . • TRACK-NO ' LAST >  of  TRACK-RECORD » 
TRACK-STORAGE-FILE  i  T-S-FI 

—  THIS  TYPE  DEFINITION  AND  OBJECT  DECLARATION  WOULD  NORMALLY  RESIDE 

—  IN  THE  BODY  OF  MANAGE-TABLES  BECAUSE  THE  PHYSICAL  IMPLEMENTATION 
--  OF  THE  FILE  SHOULD  REMAIN  HIDDEN  *  IN  THIS  CASE  DUE  TO  TESTING 

—  REQUIREMENTS  IT  MUST  BE  VISIBLE. 


end  MANAGE-TABLES5 


package  body  MANAGE-TABLES  is 

task  body  FILE-MGR  is 


besin 

loop 

select 

accept  READ_SECTOR< S  J  in  SECTOR-NO}  D  5  out  SECTOR-DATA) 


194 

195 

196 

197 

198 

199 


for  I  in  TRACK-NO ' FIRST . .TRACK-NO'LAST  loop 
D < 1 )  :=  TRACK_STORAGE_FILE (S » I ) } 
end  loop} 
end} 
or 

accept  WRITE-SECTOR (S  J  in  SECTOR-NO}  D  J  in  SECTOR-DATA) 


200  for  I  in  TRACK-NO ' FIRST TRACK-NO ' LAST  lrop 

201  TRACK-STOR AGE -FILE  <  S » I )  5=  D(I)} 
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end  loop! 


202 

203 

204 

205 

206 

207 

208 

209 

210 
211 
212 

213 

214 

215 

216 

217 

218 

219 

220 
221 
222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 


end? 

or 

accept  READ(S  J  in  SECTOR-NO!  T  J  in  TRACK-NO ! 
u  J  out  TRACK-RECORD)  do 
R  TRACK_STORAGE_FILE(S»T) ! 

end! 

or 

accept  WRITE ( S  S  in  SECTOR-NO!  T  i  in  TRACK-NO! 
R  :  in  TRACK-RECORD)  do 
TRACK-STORAGE-FILE  <S » T )  5  =  Ri 

end! 


end  select! 
end  loop* 

end  FILE-MGR!  —  body 

end  MANAGE. TABLES* 


with  VECTOR-OPERATIONS,  CALENDAR,  MANAGE-T ABLES , TRACK-TYPES » 
use  VECTOR-OPERATIONS,  CALENDAR,  MANAGE-TABLES , TRACK-TYPES! 

package  TRACKING-OPERATIONS  IS 

— ««<  FUNCTIONS  REQUIRED  BY  TRACKING  COMPONENTS  »»> 

function  DET-DEVIATION.VECT  (A  {  REPORT-POSfB  J  PREDICTED-POS ) 
return  DEVIATION-VECT i 

function  SMOCONd  J  SMOOTHING-INDEX)  return  SMOOTH-CONSTANTS! 


— ««<  PROCEDURES  REQUIRED  BY  TRACKING  COMPONENTS  »>» 
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243  procedure  PREDICTION  (X  i  in  SECTOR-NO)*  —(2. 2. 3. 4) 

244 

245  procedure  SMOOTHING  (X  :  in  SECTOR-NO)*  —(2. 2. 3. 3) 

246 

247 

248  procedure  SMOOTH-REPORT-TRACK (RN  {  in  REPORT-NO*  T  J  in  TRACK-NO* 

249  S  *  in  SECTOR-NO)* 

250  —  <2. 2. 3. 3) 

251 

252 

253 

254  task  type  TRACK-WHILE-SCAN  is  —(2.2.3) 

255  entry  NEXT_SECTOR(R  i  in  RADAR-REPORT-BUFFER)* 

256  entry  ST0P(S  J  in  SECTOR-NO)* 

257  end  TRACK-UHILE-SCAN* 

258 

259  task  SECTOR-PROCESSING-CONTROLLER  is 

260  entry  RIE-START-UP-DONE* 

261  entry  NORTH-SECTOR-PULSE* 

262  entry  NEU_SECTOR_PULSE(R  1  in  RADAR-REPORT-BUFFER)* 

263  end  SECTOR-PROCESSING.CONTROLLER* 

264 

265 

266 

267  end  TRACKING-OPERATIONS* 

268 

269  package  body  TRACKING-OPERATIONS  IS 

270 

271 

272 

273 

274  function  DET-DEVIATION-VECT  (A  J  REP0RT_P0S*B  {  PREDICTED-POS ) 

275  return  DEVIATION-VECT  IS 

276 

277  — This  function  determines  the  deviation  vector  between  a  reporl 

278  — and  a  track. 

279 

280  LOCAL  J  DEVIATION-VECT* 


begin 


281 
282 

283 

284  LOCAL  J  =  A  -  B  ? 

285  return  LOCAL ? 

286  end  DET-DEVI ATION-VECT ? 

287 

288 

289  function  SMOCONd  J  SMOOTHING-INDEX)  return  SMOOTH-CONSTANTS  IS 

290 

291  — This  function  returns  both  velocity  end  position  snoothina 

292  — constants*  See  definition  of  SMOOTH-CONSTANTS  fro* 

293  "Peckese  TRACK-TYPES. 

294 

295  bed in 

296 

297  return(SMOOTH_TABLE(I ) ) ? 

298  end! 

299 

300 

301  procedure  PREDICTION  (X  5  in  SECTOR-NO)  IS  —(2. 2. 3. 4) 

302 

303  — Prediction  reeds  a  sector  of  TRACK-RECORD(s)  utilizing  the 

304  —task  FILE-MGR. 

305  — The  position  of  each  track  is  predicted  using  the  following 

306  — eauation.  Predicted-position  =  s»oothed_position  + 

307  —  (radar_scan-tine  +  ti*e_since_previous_s*oothinS)  * 

308  —  sBOOthed-velocitw . 

309  — After  each  track  has  been  predicted  the  TRACK-RECORDS(s)  are 

310  — updated  using  the  task  FILE-MGR. 

311 

312  Y  5  SECTOR-DATA? 

313  TS  :  DURATION? 

314  SCAN-TIME  J  DURATION  5*  3.0?  —  EXPLICIT  FOR  TEST 

315 

316  begin 

317 

318  FILE-MGR. READ_SECTOR(X*Y>? 

319  FOR  I  in  TRACK-NO'FIRST . . TRACK-NO ' LAST  LOOP 

320  if  Y<I). EXISTS  then 
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321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 


TS  1=  CLOCKO  -  Y(I).T! 

--Y(I) .PRED-POS  1*  Y ( 1 > ♦ S-POS  +  (SCAN-TIME  +  TS>  *  Y(I).VEL! 
— PRECEEDING  LINE  REPLACED  FOR  TEST  PURPOSES  BY  NEXT  LINE 
—  IN  ORDER  TO  SIMULATE  ONE  RADAR  SWEEP 
Y(I) .PRED-POS  S=  Y(I). S-POS  +  6.0  *  Y(I).VEL! 
end  IF! 
end  LOOP} 

F I LE-MGR. WRITE -SECTOR (X»Y) ! 
end  PREDICTION! 

procedure  SMOOTHING  (X  5  in  SECTOR.NO)  is 


— Smoothing  assigns  the  report-to-traek  pairings  determined 
— during  ASSOCIATION  and  stored  in  ARF  (the  associated-report-f ile) 

— to  the  object  'C'. 

— The  procedure  SMOOTH-REPORT-TRACK  is  then  called  to  perform  the 
— actual  mathematical  calculations.  The  update  of  TRACK-STORAGE-FILE 
— is  doneduring  the  SMOOTH-REPORT-TRACK  procedure. 

C  J  ASSOCIATED-SECTOR! 

TN  t  TRACK-NO! 

RN  *  REPORT-NO! 


begin 

C  ! =  ARF (X) ! 

for  I  in  1. .ARF(X) .NUM-ASSOC  loop 
TN  C.PAIRS(I) .TK-NO! 

RN  !«  C.PAIRS(I) .RP-NO! 
SMOOTH-REPORT-TRACK  (RN?  TN?  X)! 
end  loop! 
end  SMOOTHING! 


procedure  SMOOTH-REPORT-TRACK  (RN  5  in  REPORT-NO! 

T  5  in  TRACK-NO!  S  5  in  SECTOR-NO)  is  —(2. 2. 3. 3) 

R  «  REPORT! 

TR  J  TRACK-RECORD! 

C  J  TIME! 

SC  !  SMOOTH-CONSTANTS! 
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361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 

382 

383 

384 

385 

386 

387 

388 

389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 


begin 


FILE-MGR . READ ( S » T »TR) ) 

— <<<<<  DETERMINE  ALTITUDE  GATE  '»»> 

R  J=  R_F(RN) } 

if  R.ALT  in  TR.ALT  -  TR . ALTGATE . . TR . ALT  +  TR.ALTGATE  then 
if  TR.ALTGATE  >  ALTITUDE-GATE 'FIRST  then 
TR.ALTGATE  S=  TR.ALTGATE  -  500} 
end  if» 


else 

if  TR.ALTGATE  <  ALTITUDE-GATE ' LAST  then 
TR.ALTGATE  l-  TR.ALTGATE  +  500} 
end  if} 


end  if} 


— «<«  END  DETERMINE  ALTITUDE  GATE  »»> 

—  ««<  BEGIN  SMOOTHING  of  ALTITUDE  (2. 2. 3. 3. 3)  »»> 
if  TR.ALTGATE  <  ALTITUDE-GATE 'LAST  then 
TR.ALT  (TR.ALT  +  R.ALT)  /  2t 

else 

TR.ALT  :*=  R.ALT} 
end  IF} 


— ««<  end  SMOOTHING  of  ALTITUDE  »»> 

—  ««<  DETECT  TRACK  MANEUVERABILITY  (2. 2. 3. 3. 4)  »»> 

—  This  block  also  determines  the  smoothing  index. 

if  TR. INDEX  =  1  then 

if  TR.CONSEC  >=  2  then 
TR. INDEX  }=  5} 

TR.CONSEC  i*  0} 
end  if} 
else 

if  TR.RGATE  then 

TR. INDEX  TR. INDEX  -  1} 
elsif  TR . OUTGATE  and  TR. INDEX  <  5  then 
TR. INDEX  S *  TR. INDEX  +  1} 
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end  if. 


401 

402  end  if} 

403 

404  —  ««<  END  DETECT  TRACK  MANEUVERABILITY  »»> 

405 

406  —  ««<  SMOOTH  VELOCITY  (2. 2. 3. 3. 2)  »»> 

407  TR.D.VEC  !  =  DET_DEVIATION_VECT ( R , POS  .  TR . PRED-POS ) } 

408  — deviation  vector  rectuired  for  smoothing  of  velocity 

409 

410  C  J=  CLOCK ( >  i 

411  SC  SM0C0N(TR. INDEX)}  —  A  FUNCTION  CALL  RETURNING  THE 

412  —  SMOOTHING  CONSTANTS 

413  —  TR.VEL  J=  TR.VEL  +  (SC.VEL  /  <C  -  TR.T>>  *  TR.D.VEC} 

414  —  THE  PRECEDING  LINE  OF  CODE  IS  REPLACED  BY  THE 

415  —  FOLLOWING  LINE  TO  SIMULATE  ONE  RADAR  SWEEP  FOR  TEST  PURPOSE 

41*  TR.VEL  :=  TR.VEL  +  ( (SC.VEL/6.0)  *  TR.D.VEC). 

417  — «<«  end  SMOOTH  VELOCITY  »>» 

418 

419  — <««  SMOOTH  POSITION  <2. 2. 3. 3.1)  »»> 

420  TR.S.POS  !  =  TR.S.POS  +  SC. POS  *  TR.D.VEC. 

421 

422  —  ««<  end  SMOOTH  POSITION  ;>»» 

423 

424  TR.T  5=  CLOCK (  )  } 

425  FILE.MGR.WRITE(S.T.TR) } 

426 

427  end  SMOOTH.REPORT -TRACK. 

428 

429  —  The  task  tape  TRACK-WHILE-SCAN  (2.2.3)  is  the  heart  of  the 

430  —  trackins  process. 

431  —  One  task  of  this  tape  will  process  reports  for  each  sector  of  the 
adar 

432  —  con ve reSe  area. 

433 

434  —  <><><><><><><><><><><>  NORMAL  OPERATION  <><><><><><><><><><><><><> 

><><> 

435 

436  —  After  a  rendezvous  with  the  SECTOR.PROCESSING.CONTROLLER  to  obta 
n  a 

437  —  sectors  worth  of  radar  reports.  TRACK.WHILE.SCAN  makes  calls  to  pe 
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438 

439 

440 

441 

442 

443 

444 

445 

446 

447 

448 

449 

450 

451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 
the 

464 

465 

466 

467 

468 

<><><> 

469 

470 

471 

472 


—  the  basic  radar  report  processing  sequence!  correlation*  association 

—  SMOOTHING  and  prediction.  TRACK_WHILE_SCAN  can  also  be  told*  via 

—  rendezvous  with  SECTOR-PROCESSING-CONTROLLER*  to  stop  current 
--  processing  and  proceed  immediately  to  prediction 

task  body  TRACK-WHILE-SCAN  is 

x  :  sector.no  * 


begin 

loop 

select 

when  STOP ' COUNT  =  0  => 

accept  NEXT-SECTOR ( R  i  in  RADAR-REPORT-BUFFER) * 
X  J=  SECT0R_N0(R)  * 

SMOOTHING  <X)* 
or 

accept  ST0F' < S  4.  in  SECT0R-N0)  i 
PREDICTION(S) * 

end  select* 
end  loop* 


end  TRACK _UHILE_SCAN* 


The  SECTOR-PROCESSING-CONTROLLER  is  the  highest  level  program  unit  trJ 
--  implementation  of  the  structure  chart  entity  TRACKING.  It  contains  t*A6 

—  control  logic  necessary  to  implement  the  scheme  of  having  one  task  to 

—  process  each  sectors  worth  of  radar  reports. 

—  <><><><><><><><><>  INITIALIZATION  <><><><><><><><><><><><><><><><><>< 


The  SECTOR-PROCESSING-CONTROLLER  is  started  up  by  the  reception  of 

—  a  signal  from  the  radar  interface  eouiptment  (RIE)  indicating  that 

—  this  device  is  ready  for  normal  service.  The  SECTOR-PROCESSING- 
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473  —  controller  then  waits  for  the  first  north  sector  pulse  to  be  trans- 

474  aitted  ba  the  RIE.  The  reception  of  this  pulse  acconpl ishes  the 

475  —  initial  sanchronization  of  the  SECTOR.RROCESSING. CONTROLLER  with  the 

476  —  radar  scan  interval. 

477 

478  —  <><><><><><><><><>  NORMAL  OPERATION  <><><><><><><><><><><><><><><><>< 

<><><> 

479 

480  —  Upon  reception  of  the  pulse  immediatela  following  the  north  sector  poiie 

481  —  the  SECTOR-PROCESSING. CONTROLLER  begins  no  reel  operation.  Normal  opec«\n>- 

482  --  consists  of  a  seouence  of  three  activities  which  take  place  in  sanchra/- 
ization 

483  —  with  radar  scar.  time.  The  three  activities  are*  1.  rendezvous  with  the 
RIE 

484  —  to  obtain  the  radar  reports  for  the  sector  just  scanned)  2*  notification 

of  •- 

485  —  the  task  processing  three  sectors  'ahead*  that  it  must  begin  prediction, 
and 

486  —  3,  initiation  of  •  -messing  the  current  sector  ba  the  appropriate  task. 

487 

488  --  <><><><><><><><><><>  ERROR  SITUATIONS  <><><><><><><><><><><><><><><>< 

<><><> 

489 

490  --  Sanchronization  with  the  RIE  Bust  be  maintained.  This  sanchronization 

is 

491  —  checked  after  the  reception  of  each  sectors  worth  of  radar  reports .  :r~  t^c 

492  —  event  of  loss  of  sanchronization  the  SECTOR-PROCESSING-CONTROLLER  wilL 

re- 

493  —  sanch  itself  to  the  sector  that  the  RIE  passed.  Tasks  processing  the 

494  —  sectors  passed  over  ba  this  re-sanch  will  return  to  sanch  on  the  next 

scan 

495  task  boda  SECT0R_PR0CESSING_C0NTR0LLER  is 

496 

497  PROCESSOR-LIST  J  arrea  (SECTOR-NO'FIRST, .SECTOR-NO'LAST) 

498  of  TRACK -WHILE- SCAN! 

499  R  J  RADAR-REPORT-BUFFER f 
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CURRENT -SECTOR  J  SECTOR-NO 


II 


begin 


accept  RIE-ST ART_UP_DONE I 
accept  NORTH- SECTOR -PULSE  I 


accept  NEW-SECTOR-PULSE < R  ♦.  in  RADAR-REPORT-BUFFER)  I 


if  SECTOR-OF(R)  /=  CURRENT-SECTOR  then — reestablish  lost  s*nchroni-z.ftTi 


send  a  message  to  the  C&C 
CURRENT-SECTOR  SECTOR.OF (R) I 


end  if! 


—  terminate  task  processing  three  sectors  ‘ahead*  of  current  sector 

PROCESSOR-LISTt (CURRENT-SECTOR  +  2)  mod  SECTOR-NO ' LAST  +  1).ST0P< 
(CURRENT-SECTOR  +  2)  mod  SECTOR-NO ' LAST  +1)1 


—  initiate  ta-sk  to  process  the  sector  data  Just  received 
PROCESSOR-LIST (CURRENT-SECTOR) .NEXT-SECTOR(R) I 


CURRENT-SECTOR  J=  CURRENT-SECTOR  mod  3ECTDR-N0 ' LAST  +  II 
end  loop} 


end  SECTOR-PROCESSING-CONTROLLER} 


end  TRACKING-OPERATIONS! 


no  parse  errors  detected 
Parsing  time!  426  seconds 


